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APPROACHES  TO  MANAGING  FUTURE  TRAINING 

EXECUTIVE  SUMMARY 


Research  Requirement: 

As  the  U.S.  Army  transformation  to  the  Future  Force  equipped  with  the  Future  Combat 
Systems  (FCS)  moves  forward,  system  design  and  development  decisions  are  made  daily.  In 
parallel,  there  are  training  design  and  development  decisions  that  support  the  delivery  of  realistic 
and  targeted  training,  anywhere  and  anytime,  by  means  of  embedded  training  (ET).  Unit 
members  will  be  participating  in  training  while  they  are  seated  in  their  vehicles  or  at  their 
workstations,  using  the  system  controls  and  interfaces  just  as  they  would  operationally,  and  the 
training  content  will  be  presented  through  those  interfaces. 

Because  the  system  capabilities  are  being  designed  now,  those  who  are  working  on 
managing  future  training  need  to  address  the  issues  surrounding  efficient  and  effective  use  of 
embedded  training  capabilities.  The  intent  of  this  research  of  the  U.S.  Army  Research  Institute 
for  the  Behavioral  and  Social  Sciences  (ARI),  was  to  identify  the  issues  associated  with  the 
management  of  collective  training  for  Future  Force  Soldiers,  leaders,  and  units,  and  to  design  a 
detailed  approach  for  that  training  management.  Of  particular  interest  was  the  way  that  future 
embedded  training  could  be  adaptable — amenable  to  changes  in  response  to  training  needs,  with 
minimal  programming  or  laborious  administrative  effort. 

Procedure: 

Initial  project  activities  consisted  of  identifying  and  obtaining  materials  relevant  to  the 
project  objectives.  Information  on  current  initiatives  within  U.S.  Department  of  Defense  (DoD) 
was  gleaned  from  conversations  with  experts  and  from  documentation  available  on  the  internet. 
The  vast  majority  of  information  on  FCS  capabilities  is  still  evolving,  so  many  of  the  materials 
examined  were  draft  and  preliminary  copies.  The  information  was  reviewed  and  analyzed  by  a 
shifting  group  of  experts,  including  individuals  from  ARI,  the  FCS  team  focused  on  collective 
training,  and  other  military  and  training  experts.  This  analysis  consisted  of  categorizing 
information,  identifying  consistencies  and  inconsistencies,  and  establishing  linkages  and  shared 
capabilities.  The  information  was  used  to  formulate  and  explore  five  issues  related  to  future 
training  management: 

•  Expectations  for  future  training  development  and  delivery,  based  on  FCS  network 
services  planning  and  training  roles. 

•  Types  of  information  and  tools  that  users  will  need  for  planning  and  conducting 
collective  training. 

•  Methods  for  providing  the  information  and  tools,  based  on  current  and  emerging  Army 
database  initiatives  and  status  of  computer-generated  forces  (CGF)  and  artificial 
intelligence  (AI)  technologies. 


v 


•  Expectations  of  the  kind  of  tools  (i.e.,  how  much  automation)  users  will  accept, 
acknowledging  commanders’  need  to  insert  their  own  expertise  and  expectations  into 
exercises  rather  than  allow  an  automated  system  to  make  decisions  and  act  as  the  expert. 

•  Assessment  of  successful  near-term  development  of  the  anticipated  tools  and  capabilities 
and  description  of  the  nature  of  near-term  solutions. 

The  issues  were  further  explicated  by  means  of  informal  use  cases  for  future  training 
development  and  execution.  Use  cases  focused  on  units  and  unit  commanders  were  used  to 
formulate  secondary  use  cases  targeting  the  conceptual  future  training  management  system, 
which  were  decomposed  to  identify  the  specific  capabilities  that  would  be  required.  By  linking 
the  needed  capabilities  and  their  purposes  to  plans  and  expectations  for  FCS  capabilities  and  then 
determining  the  likelihood  of  technology  maturity  within  the  next  10  years,  the  project  team 
delineated  specific  recommendations  concerning  training  management  possibilities  and  needs  for 
further  research  and  development. 

Findings: 

The  concept  for  future  training  management  provides  a  detailed  description  of  how 
collective  training  exercises  can  be  developed  and  delivered,  given  a  suite  of  technologically 
sophisticated  services  including  massive  database  systems,  bi-directional  reach  (both  accessing 
and  sending  needed  information),  sophisticated  self-learning  search  engines,  performance 
support  systems,  CGF  simulations  powered  by  AI,  and  super-broad  bandwidth.  A  more  realistic 
near-term  approach  is  also  described,  along  with  discussion  of  research  and  development 
recommendations  focused  on  how  the  needed  information  and  tools  can  be  provided.  The 
findings  have  necessarily  been  edited  to  avoid  specific  information  about  FCS  decisions  that  are 
not  yet  final. 

Utilization  and  Dissemination  of  Findings: 

The  results  of  this  project  can  benefit  those  involved  in  further  definition  and  development 
of  the  training  management  capabilities  for  the  transformation  to  the  Future  Force  equipped  with 
FCS.  In  addition,  the  research  and  development  issues  provide  direction  for  future  work  that  will 
assist  the  Army  in  achieving  its  stated  goals  for  the  Future  Force. 
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APPROACHES  TO  MANAGING  FUTURE  TRAINING 


Introduction 

As  the  U.S.  Army  transformation  to  the  Future  Force  equipped  with  the  Future  Combat 
Systems  (FCS)1  moves  forward,  system  design  and  development  decisions  are  made  daily. 
Myriad  engineers,  programmers,  and  modeling  and  simulation  experts  have  joined  forces  with 
military  experts  to  create  and  integrate  the  components  of  the  envisioned  FCS:  a  fully- 
networked  system  of  systems,  enabling  rapid  and  complete  sharing  of  information  across 
echelons,  leaders,  and  systems — throughout  the  full  battlespace.  The  heart  of  the  information- 
sharing  capability  will  be  the  system  of  systems  common  operating  environment  (SOSCOE), 
supporting  multiple  applications  that  serve  a  wide  array  of  information  demands.2 

With  these  system  decisions  come  training  design  and  development  decisions  addressing 
the  delivery  of  realistic  and  targeted  training,  anywhere  and  anytime.  Again,  the  SOSCOE  is  at 
the  heart  of  the  capability.  The  integrated  information-sharing  environment  will  make  it  possible 
to  meet  all  training  needs,  from  individual  Soldier  training  to  large  scale  collective  exercises, 
while  participants  are  seated  in  their  vehicles  or  a  tactical  command  post  (TACP),  or  in  high 
fidelity  networked  training  venues  known  as  networked  reconfigurable  full  task  trainers 
(NRFTT).  This  training  capability  will  take  advantage  of  technologies  such  as  massive  database 
systems,  bi-directional  reach  (both  accessing  and  sending  needed  information),  sophisticated  • 
self-learning  search  engines,  performance  support  systems,  computer-generated  forces  (CGF)- 
simulated  conditions  and  participants  powered  by  artificial  intelligence  (AI),  and  super-broad 
bandwidth,  to  allow  Soldiers  and  leaders  to  get  the  training  they  need  at  the  exact  moment  that 
they  need  it. 

The  capability  to  provide  this  type  of  training  is  referred  to  as  an  embedded  training 
capability.  Unit  members  will  be  participating  in  training  while  they  are  seated  in  the  vehicles  or 
at  the  workstations  in  the  TACP,  and  they  will  be  using  the  system  controls  and  interfaces  while 
they  are  in  training,  just  as  they  would  operationally,  and  the  training  content  will  be  presented 
through  those  interfaces.  That  method  of  delivery  and  point  of  participation  is  what  makes  the 
.  training  embedded.  The  capability  is  so  critical  within  the  FCS  development  plan  that  it  has  been 
designated  as  a  Key  Performance  Parameter  (KPP)  for  acquisition  of  the  FCS  family  of  systems. 

That,  at  least,  is  the  plan  and  the  vision.  It  is  more  than  a  little  ambitious,  depending  as  it 
does  on  the  use  of  technologies  that  are  not  yet  mature  or  even,  in  some  cases,  much  beyond  the 
drawing  boards.  For  individual  training,  the  delivery  will  closely  resemble  computer-based 
instruction  or  web-mediated  instruction.  For  collective  training,  where  unit  members  may  be 
located  on  opposite  sides  of  the  country  or  the  globe,  delivery  of  exercises  presents  a  much  more 
complex  picture.  Yet,  with  designation  as  a  KPP,  the  embedded  training  capability  has  become 
non-negotiable:  it  will  be  realized.  In  one  form  or  another  (yet  to  be  fully  comprehended), 


1  Appendix  A  contains  a  list  of  the  acronyms  and  abbreviations  used  in  this  report. 

2  Think  of  it  as  Windows®  on  steroids,  where  you  can  pull  and  push  products  from  all  of  the  applications — 
Microsoft®  (MS)  Word,  MS  Excel,  Adobe  Photoshop,  and  so  on — with  no  apparent  translation  machinations  and 
complete  reliability  and  accuracy.  Then  multiply  that  by  about  a  hundred.  That  is  a  pale  imitation  of  the  envisioned 
SOSCOE  capability. 
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training  will  be  delivered  to  unit  members  in  their  vehicles  or  TACP  workstations,  through  the 
normal  user  interface,  as  they  use  system  controls.  In  some  fashion,  all  training  will  be  available 
anytime,  anywhere,  and  that  includes  on  the  vehicles. 

This  reality  (or  vision  foreshadowing  reality)  gives  rise  to  a  training  management 
imperative:  The  issues  associated  with  management  of  future  training  must  be  identified, 
examined,  and  addressed  in  parallel  with  the  design  and  development  of  the  systems  that  will 
provide  future  training.  The  system  capabilities  are  being  designed  now,  and  the  recognition  of 
issues  and  formulation  of  approaches  for  the  efficient  and  effective  use  of  embedded  training 
capabilities  is  essential.  This  will  be  a  continuing  task  for  integrated  teams  of  training  design 
experts,  engineers,  programmers,  modelers,  and  military  experts.  The  unique  role  for  the 
training  designers  and  researchers  is  to  clearly  identify  the  issues  and  apply  relevant  research  and 
development  (R&D)  experience  to  defining  resolutions  from  the  training  management 
perspective. 

To  that  end,  the  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 
(ARI)  sponsored  research  to  identify  the  issues  associated  with  the  management  of  collective 
training  for  Future  Force  Soldiers,  leaders,  and  units,  and  to  design  a  detailed  approach  for  that 
training  management.  Of  particular  interest  was  the  way  that  future  embedded  training  could  be 
adaptable — amenable  to  changes  in  response  to  training  needs,  with  minimal  programming  or 
laborious  administrative  effort.  In  the  course  of  that  research,  a  host  of  other  issues  surfaced 
related  to  training  management,  issues  that  recognize  the  way  in  which  training  is  a  part  of  the 
larger  system  of  Army  and  Department  of  Defense  (DoD)  operational  requirements  and  human 
resource  management. 

This  report  is  the  product  of  the  research.  Its  purpose  is  to  describe  issues  and 
recommendations  related  first  to  providing  adaptable  training,  and  then  also  to  management  of 
training  in  the  future,  when  FCS,  embedded  training  (ET)  capabilities,  and  a  full  range  of 
personnel  management  tools  are  the  norm  for  daily  operations.  The  report  also  discusses 
research  issues  and  procedural  questions  that  will  need  to  be  addressed  in  order  to  provide 
effective  and  efficient  training  for  the  Future  Force. 

The  report  first  discusses  the  issues  associated  with  management  of  future  training  (as  well 
as  some  of  the  non-issues)  and  related  current  and  emerging  Army  initiatives,  FCS 
documentation,  and  previous  ARI  research  findings.  The  concept  for  a  future  training 
management  system  is  then  described  through  use  cases.  We  then  present  a  set  of  detailed 
recommendations,  including  priorities,  “fail-back”  solutions  for  near-  and  long-term 
development,  and  directions  for  further  research  and  development  in  both  training  and 
technology  realms. 

Issues  Associated  with  Future  Training  Management 

For  about  the  past  10  years,  large-scale  collective  training  events  have  come  to  be  closely 
associated  with  (and  even  confused  with)  the  training  support  packages  (TSPs)  that  make 
conduct  of  those  exercises  possible.  In  general,  the  term  “training  support  package,”  or  TSP, 
refers  to  all  of  the  information  and  products  that  would  allow  a  structured,  scenario-based 
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exercise  to  be  conducted  with  some  degree  of  standardization.  The  U.S.  Army  Training  and 
Doctrine  Command  (TRADOC)  Pamphlet  350-70-1  (Department  of  the  Army  [DA], 
Headquarters,  2004)  defines  a  TSP  as,  “a  complete,  task-based,  exportable  package  integrating 
training  products,  materials,  and  information  necessary  to  train  one  or  more  critical  tasks”  (p. 

65).  Scrupulous  use  of  a  well-constructed  TSP  ensures  that  realistic  and  doctrinally  correct 
situations  are  presented,  training  objectives  are  addressed,  appropriate  observations  and 
assessments  are  made,  and  targeted  feedback  is  given  to  the  participants  (Campbell,  Campbell, 
Flynn,  Sanders,  &  Myers,  1995;  Gossman,  Graves,  Mauzy,  &  Clagg,  2001).  When  we  refer  to 
TSPs  in  this  report,  we  do  not  mean  the  training  event  itself,  or  a  broad  program  of  unit 
training — we  mean  the  package  of  material  that  enables  conduct  of  the  training,  whether 
packaged  in  digital  text  and  graphics  files,  on  paper,  or  in  some  futuristic  automated  system. 

Ten  years  ago,  TSPs  were  almost  entirely  packaged  as  printed  text  on  paper.  As  embedded 
training  capabilities  loom,  however,  there  is  widespread  recognition  that  that  approach  must 
change.  In  a  recent  report  that  synthesizes  much  of  ARI’s  research  on  TSPs  for  collective 
training,  Burnside  and  Throne  (2004)  identified  five  distinct  capabilities  that  embedded  training 
systems  must  provide.  These  include: 

•  rapid  tailoring  or  modification  of  training  events  based  on  the  users’  needs, 
performance,  and  choice; 

•  bi-directional  reach  to  and  from  remote  knowledge  centers  to  obtain  updates  or  to 
access  and  exchange  additional  products; 

•  a  simulated  operating  environment  that  has  the  capability  to  address  all  aspects  of  the 
training  environment  that  are  not  physically  present  (e.g.,  terrain,  enemy,  other  friendly 
units,  unit  personnel),  and  must  therefore  be  represented  synthetically; 

•  semi-automated  performance  measurement  for  assessment  and  feedback;  and 

•  pretests  or  selection  criteria  for  entry  into  a  training  event,  based  on  identified 
individual  and  collective  performance  weaknesses. 

The  capabilities  described  by  Burnside  and  Throne  (2004)  cannot  be  incorporated  as 
features  of  individual  self-contained  TSPs  that  support  defined  training  events,  even  if  the  TSPs 
migrate  from  paper  to  electrons.  They  will  only  be  achieved  through  the  framework  of  a  training 
management  system  that  integrates  the  tools  and  allows  them  to  operate  in  concert  with  the 
individual  TSPs.  The  five  capabilities  are  intertwined  and  thus  will  require  a  powerful  training 
management  system  that  draws  on  information  resources  outside  the  separate  TSPs  to  adapt 
training  events,  access  information  in  various  repositories,  simulate  various  combination  of 
conditions,  measure  and  assess  performance,  and  evaluate  training  readiness  and  achievement. 

In  formulating  a  conceptual  description  of  the  future  training  management  system,  we 
began  by  listing  out  the  issues.  Our  initial  set  was  eventually  reduced  to  a  critical  set  of  five: 


3 


1 .  What  will  future  training  development  and  delivery  be  like,  given  the  technologies  and 
mandates? 

2.  What  kind  of  information  and  tools  will  training  managers  and  exercise  controllers 
need? 

3.  How  will  the  information  and  tools  be  provided  (or  obtained,  or  produced)? 

4.  What  kind  of  tools  (i.e.,  how  much  automation)  will  the  training  managers  accept? 

5.  For  tools  and  capabilities  that  are  far  off  in  the  future,  what  are  the  near-term  solutions? 

These  five  topics  form  the  organizing  construct  for  this  report.  This  section  presents  a 
summary  of  our  understanding  of  the  five  issues,  as  well  as  a  short  discussion  of  topics  (referred 
to  as  non-issues)  that  have  already  been  recognized  and  addressed  and  should  no  longer  be 
issues  of  major  concern. 

What  Will  Future  Training  Development  and  Delivery  Be  Like? 

Without  a  crystal  ball,  we  can  still  construct  a  somewhat  cloudy  vision  of  the  training 
development  and  delivery  of  the  future.  A  primary  source  of  information  is  the  documentation 
that  emerges  from  the  FCS  design  efforts,  and  particularly  from  the  FCS  Training  Systems 
Integration  Integrated  Product  Team  (IPT).  The  premise  for  future  training,  described  in  the 
Training  IPT’s  Training  Management  Plan,  is  that  collective  training  must  be  available  on 
demand  and  will  be  delivered  by  means  of  embedded  training  capabilities.3  Our  understanding 
of  the  functioning  of  future  training  was  shaped  by  examination  of  the  Training  IPT  work  and 
other  products  from  FCS  teams  who  are  working  on  training  issues.  The  subsections  below 
provide  short  reviews  of  several  areas  of  FCS  R&D: 

•  Requirements  analysis  for  FCS  Training  Common  Components  (TCC). 

•  Software  services  supporting  FCS  battle  command.  . 

•  Training  roles,  both  human  and  automated. 

Requirements  Analysis  for  FCS  Training  Common  Components.  The  Training  IPT  is 
working  with  the  Program  Executive  Office  for  Simulation,  Training,  and  Instrumentation 
(PEOSTRI)  to  define  the  basic  software  components  that  will  support  embedded  individual  and 
collective  training.  The  initial  baseline  in  creation  of  these  TCCs  was  derived  from  software 
capabilities  developed  through  Army-sponsored  programs.  In  an  analysis  of  requirements  for 


3  The  Training  Management  Plan  (FCS  Training  Systems  Integration  IPT,  2005)  is  classified  by  Boeing  and  SAIC, 
the  FCS  Lead  Systems  Integrator  (LSI),  as  Distribution  D  -  Distribution  authorized  to  the  Department  of  Defense 
and  U.S.  DoD  contractors  (Administrator  or  Operational  Use).  Those  wishing  to  view  the  plan  should  contact  the 
LSI.  Additionally,  a  more  detailed  version  of  this  report,  which  would  also  be  classified  as  Distribution  D,  was 
prepared  for  ARI. 
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software  components  that  will  support  training,  a  number  of  tools  and  functions  are  described.4 5 
The  definitions  and  the  longer  descriptions  conjure  up  a  rich  descriptive  picture  of  embedded 
training  capabilities.  However,  they  are  at  this  stage  very  general  and  largely  from  the  point  of . 
view  of  the  system,  not  the  human  user. 

Battle  Command  Software  Services.  Additional  FCS  design  information  is  found  in 
descriptions  of  the  Battle  Command  Software  Services  (BCSS).  Like  the  TCCs,  these  services 
are  applications  that  are  available  through  the  SOSCOE.  The  descriptions  of  the  services  and 
subservices  (the  features  and  capabilities  of  each)  are  not  constrained  by  considerations  of  what 
is  possible  today.  Neither  are  they  yet  very  specific  in  how  these  services  will  be  provided. 
However,  as  noted  by  Mauzy,  Flynn,  Dannemiller,  and  Gossman  (2003),  services  and  systems 
that  support  performance  during  operations  should  also  be  incorporated  in  training.  This  is  more 
than  a  matter  of  “train  as  you  fight.”  In  fact,  such  performance  support  services  can  also  be 
useful  in  designing  training  events  and  constructing  TSPs  as  well  as  in  conducting  the  training. 

Human  and  Automated  Training  Roles.  In  addition  to  descriptions  of  software  services 
and  components,  the  human  role  in  future  training  is  being  defined.  The  definition  of  training 
roles  is  seen  as  essential  for  FCS  software  developers  to  understand  the  needed  features  and 
capabilities  of  the  embedded  training  systems,  as  well  as  the  demands  that  will  be  placed  on  the 
SOSCOE.  A  role  is  not  a  duty  position,  nor  is  it  inextricably  linked  to  any  particular  duty 
position.  Rather,  on  any  given  day,  one  of  any  number  of  individuals,  from  platoon  leaders  to 
battalion  commanders  and  staff,  could  be  designated  to  perform  the  role.  In  general,  the 
functions  currently  performed  by  humans  that  will  require  assignments  in  the  future  include: 

•  a  training  manager,  who  makes  decisions  about  what  training  will  be  conducted; 

•  an  exercise  controller,  who  actually  monitors  and  directs  a  training  exercise;  and 

•  a  CGF  operator,  who  controls  the  behaviors  of  entities  in  simulation.6 

The  still-evolving  working  definitions  contain  considerable  detail  on  the  specific  actions 
that  would  need  to  be  performed.  A  notable  feature  is  that,  at  this  point  in  time,  the  roles  are 
fully  anthropomorphic,  that  is,  expressed  as  though  performed  by  humans.  Given  the  rapid 
advances  being  made  in  the  use  of  broadband  networks,  complex  databases,  intelligent  agents, 
and  collaborative  tools,  many  of  the  activities  that  are  at  present  assigned  to  humans  should 
eventually  be  relegated  to  automated  systems.  This  is  not  a  startling  insight,  nor  inconsistent 
with  expectations  of  the  Training  IPT;  it  merely  reflects  the  difference  between  realistic  near- 
term  planning  (for  the  2012-2016  timeframe)  and  more  fantastic  long  term  aspirations. 


4  The  Requirements  Analysis  for  FCS  Training  Common  Components  (FCS  Training  Common  Component 
Technical  Integrator,  2004),  describes  the  planned  software  assets.  The  Requirements  Analysis  has  not  been 
designated  for  open  distribution.  Those  wishing  to  view  the  analysis  should  contact  the  LSI. 

5  Descriptions  of  the  Battle  Command  Support  Services  are  still  under  development  and  have  not  been  designated 
for  open  distribution.  Those  wishing  to  view  descriptions  should  contact  the  LSI. 

6  Definitions  of  the  roles  and  their  specific  responsibilities  are  still  under  development  and  have  not  been  designated 
for  open  distribution.  Those  wishing  to  view  descriptions  should  contact  the  LSI. 
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The  FCS  Training  IPT  has  made  impressive  progress  in  translating  the  FCS  Operational 
Requirements  Document  ([ORD]  Unit  of  Action  Maneuver  Battle  Laboratory,  2002)  into 
increasingly  detailed  descriptions  of  services  and  human  roles,  so  that  engineers,  programmers, 
military  experts,  and  training  experts  can  have  a  common  understanding  of  the  necessary  design 
and  development  products.  The  FCS  documentation  is  convergent  overall,  with  only  minor 
inconsistencies  that  are  likely  an  artifact  of  semantics  rather  than  internal  conflicts  or  gaps  in 
planning.  Although  the  design  and  development,  and  the  documentation  itself,  are  still  works  in 
progress,  the  degree  of  convergence  suggests  that  the  information  is  reliable  and  sufficiently 
mature  to  serve  as  the  basis  for  further  analysis. 

Armed  with  those  descriptions  of  the  FCS  operational  and  training  system  requirements, 
technology  services,  and  roles  of  humans  interacting  with  services,  we  formulated  informal  use 
cases  that  portray  the  training  development/delivery/management  system  in  operation.  As  the 
Training  IPT  continues  its  efforts,  we  expect  that  they  will  further  explicate  the  descriptions  into 
specific  elements  by  means  of  detailed,  formal  use  cases.  Our  initial  version  of  these  products  is 
contained  in  the  next  major  section,  following  discussion  of  the  other  issues. 

What  Kind  of  Information  and  Tools  Will  Users  Need? 

Among  the  users  and  uses  that  were  culled  from  review  of  the  various  products  and  think 
pieces,  the  following  (broad  but  not  particularly  deep)  descriptions  of  users  and  uses  emerged: 

•  For  individual  Soldiers  (including  everyone  from  the  Private  to  the  Command  Sergeant 
Major,  from  the  Second  Lieutenant  to  the  General  Officer)  who  are  interested  in  their 
own  training — the  capability  to  see  what  training  they  have  completed,  what  training 
they  could  do  next,  and  what  opportunities  are  available  for  those  requirements;  a  way 
to  sign  up  for  or  schedule  individual  training;  options  for  additional  non-required 
individual  training. 

•  For  unit  leaders  and  their  staffs — the  capability  to  view  data  on  individual  and  unit 
readiness  and  plan  further  training  by  reviewing  training'completed,  progression 
specified  in  their  Combined  Arms  Training  Strategy  (CATS),  and  opportunities  are 
available  for  training;  tools  to  modify  their  CATS  as  their  missions  change;  a  way  to 
sign  up  for  or  schedule  unit  training;  options  for  additional  non-required  training. 

•  For  training  facility  managers — tools  for  monitoring  use  of  live  training  areas, 
constructive/virtual  simulation  facilities,  and  NRFTT  sites,  reviewing  and  adjusting 
schedules  with  unit  leaders,  scheduling  routine  or  situation-driven  maintenance  of  their 
facilities. 

•  For  organizations  engaged  in  training  and  doctrine  development — the  capability  to 
monitor  currency  and  quality  of  training  materials  and  training  support  packages,  make 
any  necessary  updates  with  very  short  turnaround  time,  provide  rubrics  on  skill  decay, 
prepare  and  incorporate  optimal  schedules  for  refresher  training,  construct  baseline 
tables  of  organization  and  equipment  (T.O&E)  training  strategies  (e.g.,  CATS)  and 
formulate  options  within  those  strategies. 
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•  For  personnel  managers — the  ability  to  monitor  individual  training  opportunities  and 
availability  by  means  of  both  regular  and  on-demand  reports  of  fill  rates,  seats 
available,  requirements  for  training;  the  capability  to  forecast  training  availability 
through  “what  if’  simulations;  tools  to  optimize  personnel  assignments  .based  on 
proficiency;  tools  to  monitor  completion  of  required  training  and  professional 
development  for  promotion  purposes. 

The  first  three  of  those  users  and  uses  concern  planning  and  scheduling  of  training.  The 
fourth  one,  referring  to  the  process  for  making  prepared  training  modules  and  TSPs  available  for 
users,  clearly  belongs  under  training  management  as  a  sort  of  planning  function,  although  it  is 
decidedly  different  from  the  first  three.  The  last  one  addresses  use  of  archived  training  data  for 
non-training  purposes,  and  is  only  tangentially  a  training  management  concern.  Although  these 
requirements  address  a  number  of  uses  and  users,  they  should  be  seen  as  parts  of  a  single 
multipurpose  system:  all  of  the  functions  described  above  are  intertwined  and  will  need  to  share 
information. 

Conspicuously  missing  in  those  discussions  and  plans  is  a  description  of  how  the  training 
of  the  future  can  be  provided  anytime,  anywhere,  and  how  to  make  it  readily  adaptable  by 
Soldiers  and  units,  as  described  in  various  ARI  research  products  (e.g.,  Campbell  &  Holden, 
2001;  Gossman,  Flynn,  &  Breidenbach,  2004;  Throne  &  Burnside,  2003).  Thus,  another  use  was 
noted: 


•  Additionally,  for  individuals,  small  groups,  and  units — a  means  for  on-demand  delivery 
of  training,  over  the  (future)  network,  as  interactive  multimedia  instruction,  small  group 
instructor-led  instruction  (synchronous  or  asynchronous),  small  group  multiplayer 
exercises,  or  unit  collective  simulation-based  exercises;  facility  for  producing  tailored 
exercises  and  accompanying  TSPs  to  target  specific  tasks,  scenarios,  and  participating 
individuals  or  units;  capability  to  modify  existing  exercises  quickly  (even  “on  the  fly”); 
support  for  conducting  training  with  less  than  full  unit  participation;  automated  data 
archiving;  facility  for  leaders  to  modify  training  events  and  annotate  archived  data  for 
unit  needs. 

All  of  these  users  and  uses  have  a  vested  interest  in  the  training  management  of  the  future. 
However,  our  primary  focus  in  this  effort  is  on  collective  training — development,  delivery, 
feedback,  and  data  archiving.  Thus,  the  uses  and  users  of  interest  are  the  unit  leaders  planning 
collective  training  and  the  units  participating  in  adaptable  collective  training.  The  use  cases 
described  in  the  next  major  section  were  based  on  these  initial  descriptions. 

How  Will  the  Information  and  Tools  be  Provided? 

The  emerging  FCS  documentation,  some  of  which  was  described  above,  gives  a  general 
overview  of  what  software  services  are  being  planned  to  support  training  development,  delivery, 
and  management.  The  description  begs  the  question  of  where  the  information  that  those  services 
use  will  come  from.  Several  prime  sources  are  likely  candidates,  including  the  Army  Training 
Information  Architecture  (ATIA),  the  Common  Training  Instrumentation  Architecture  (CTIA), 
and  the  Unit  Training  Management  Component  (UTMC;  sometimes  referred  to  as  the  Unit 
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Training  Management  Configuration).  These  are  large,  complex  database  systems  that  contain 
doctrinal  information  about  individual  and  collective  tasks;  unit  information  such  as  their  CATS 
and  Mission  Essential  Task  List  (METL);  individual  and  unit  training  history;  linkages  to  other 
databases  that  permit  scheduling  and  resource  planning;  and  semi-automated  tools  to  assist 
training  personnel  in  managing  the  information  for  their  own  training  needs.  Clearly,  one 
expectation  is  that  the  extensive  research  and  development  that  has  already  been  focused  on  tools 
for  training  management  should  not  be  scrapped. 

The  resources  that  we  examined  yielded  descriptions  of  a  core  set  of  databases  that  may 
serve  as  the  source  for  future  training  management.  Most  of  the  effort  is  focused  on  immediate 
and  near-term  solutions,  designed  to  address  the  frustrations  experienced  today  with  the 
technologies  available  today.  Nonetheless,  four  database  systems  seem  likely  to  be  useful  for 
Future  Force  training,  as  they  are  now  (or  should  be  in  the  near  future)  for  Current  Forces.  They 
are  described  briefly  below.  As  concerns  tools,  some  of  those  are  integral  to  the  database 
systems.  Others,  though,  will  make  use  of  highly  realistic  AI  and  CGF.  A  brief  summary  of  the 
current  and  emerging  developments  on  AI  and  CGF  is  also  presented  below.  The  ensuing 
discussions  address: 

•  the  CATS  program. 

•  the  Digital  Training  Management  System. 

•  the  Army  Training  Information  System. 

•  the  Defense  Integrated  Military  Human  Resources  System. 

•  advances  in  CGF  and  AI. 

Combined  Arms  Training  Strategy.  One  such  initiative  is  the  CATS  program,  the  Army’s 
overarching  strategy  for  current  and  future  training  of  the  force.  Its  basis  is  a  series  of  branch- 
proponent  unit  and  institutional  strategies  describing  training  events,  event  frequencies,  and 
resources  required  to  train  to  standard.  These  strategies  describe  how  the  Army  will  train  the 
total  force  to  standard  through  self-development,  institutional  training,  and  in  units.  They  also 
document  the  quality  of  and  justification  for  all  training  resources  required  to  execute  the 
training.  The  automated  CATS  module  (currently  a  part  of  the  Automated  Systems  Approach  to 
Training  [ASAT])  allows  training  developers  to  produce  individualized  training  strategies  using 
automated  tools.  It  identifies  training  events  using  a  crawl-walk-run  training  methodology; 
provides  a  conceptual  training  calendar  that  lays  out  the  training  events  under  perfect  training 
conditions;  and  outlines  the  recommended  number  of  times  tasks  should  be  trained  during  one 
training  year  based  on  an  interval  that  considers  key  personnel  turbulence,  skill  decay,  mission 
changes,  and  task  complexity.  For  every  training  event,  there  are  details  that  outline  the  purpose, 
outcome,  recommended  training  audience,  means  (including  training  aids,  devices,  simulators, 
and  simulations,  or  TADSS),  estimated  event  duration,  critical  training  gates  (i.e.,  prerequisite 
training  or  readiness  criteria),  and  execution  guidance. 
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Digital  Training  Management  System7.  A  promising  tool  that  builds  on  the  information 
found  in  the  CATS  is  the  Digital  Training  Management  System  (DTMS).  The  DTMS  is  a 
customized  commercial-off-the-shelf  (COTS)  product  provided  by  nFocus  Software®.  An 
Information  Paper  describes  the  system  as  .  .a  user-friendly  web-based  unit  training 
management  system  for  units  at  all  levels  to  track  and  manage  their  unit  training  ...  [It  is] 
optimized  to  support  unit  training  management  from  company  to  brigade  level”  (Collective 
Training  Directorate,  2005a).  Through  the  DTMS,  unit  leaders  and  trainers  can  detail  the  unit’s 
METL,  personnel,  and  modified  tables  of  organization  and  equipment  (MTO&E);  view  CATS 
and  schedule  training;  review  training  assessments  and  after  action  reviews  (AARs);  and  both 
examine  and  add  to  a  library  of  references.  According  to  the  DTMS  training  site  (Collective 
Training  Directorate,  2005b),  it  is  (or  is  going  to  be)  linked  in  real  time  to  a  host  of  other 
databases,  including: 

•  Personnel  systems  (e.g.,  EMilpo-Electronic  Military  Personnel  Office,  ITAPdB- 
Integrated  Total  Army  Personnel  Database,  SIDPERS-Standard  Installation/Division 
Personnel  System), 

•  Training  facility  and  resource  systems  (e.g.,  RFMSS-Range  Facility  Management 
Support  System,  ATRRS-Army  Training  Requirements  and  Resources  System, 
TAMIS-R-Training  Ammunition  Management  Information  System-Redesign,  TESS- 
Tactical  Engagement  Simulation  System),  and 

•  Task  and  training  information  systems  (e.g.,  CALL-Center  for  Army  Lessons  Learned, 
ATIS-Army  Training  Information  System,  ITRS-Individual  Training  Readiness 
System). 

Army  Training  Information  System.  As  it  turns  out,  the  DTMS  is  subsumed  under  one  of 
the  systems  that  are  shown  as  a  supporting  database:  the  ATIS,  which  is  overseen  by 
TRADOC’s  Army  Training  Support  Center  (ATSC).  The  ATIS  is  “. .  .a  system  of  systems  that 
brings  together  myriad  functions  in  one  comprehensive  Army  training  system.  [The]  ATIS  uses 
the  [World-Wide  Web]  to  access  an  all  inclusive  digital  library  and  data  repository  through  a 
suite  of  software  applications  including:  training  development;  individual  training  management; 
unit  training  management;  and  common  core  services  available  to  all  through  the  Soldier 
Training  Homepage”  (Total  Army  Distance  Learning  Program  [TADLP],  2005).  Functions  and 
information  currently  found  in  ASAT,  such  as  task  analysis  products,  are  to  be  migrated  to  ATIS 
(TADLP,  2005). 

The  key  software  applications  of  the  system  are  (or  will  be): 

•  Training  and  Doctrine  Development  Tool  (TDDT)— -used  by  the  training  development 
community  to  create  and  develop  the  source  doctrine  and  training  materials  required  to 
develop  training  products. 


7  The  “Digital  Training  Management  System”  (DTMS)  is  a  database  product  that  satisfies  most,  if  not  all,  of  the 
requirements  for  the  UTMC. 
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•  Army  Learning  Management  System  (ALMS) — delivers  standardized  individual 
training  to  Soldiers,  providing  a  fully  automated,  seamless  and  web-accessible  training 
and  education  network;  provides  users  a  common  “tabbed”  start  page  from  which  they 
can  access  the  other  configurations,  materials  in  the  Reimer  Digital  Library  and 
Common  Core  Services  of  the  data  repository. 

•  The  UTMC — provides  the  functionality  to  analyze,  manage,  plan,  conduct,  evaluate, 
and  provide  feedback  on  unit  training  and  is,  in  fact,  the  defining  requirement  for  the 
DTMS. 

Defense  Integrated  Military  Human  Resources  System.  To  round  out  the  picture,  there  is 
an  even  more  overarching  system:  The  Defense  Integrated  Military  Human  Resources  System 
(DIMHRS).  The  DIMHRS  is  a  congressionally-mandated  program  which  crosses  all  military 
services.  It  consists  of  three  functional  areas,  named  Personnel  and  Pay,  Manpower,  and 
Training.  Its  origins  are  in  a  realization  that  each  military  service  (Army,  Navy,  and  Air  Force) 
has  had  separate  systems,  which  comprise  over  160  documented  redundant  systems,  databases, 
and  interfaces — and  that  was  only  for  personnel  and  pay  functions.  This  resulted  in  significant 
gaps  in  personnel  management,  including  the  inability  to  track  active  and  reserve  status  changes, 
account  for  personnel  in  theater,  maintain  consistent  service  records,  and  ensure  adequate 
security  of  personal  information.  As  envisioned,  DIMHRS  will  provide  real-time  accurate 
information  to  Soldiers,  human  resources  professionals,  and  commanders  from  non-redundant 
databases. 

The  personnel  and  pay  functions  have  been  captured  in  the  subsystem  of  DIMHRS  known 
as  the  Enterprise  Human  Resources  System,  which  is  now  in  initial  fielding  beginning  with  the 
Army  and  to  be  followed  by  the  Navy  and  Air  Force.  Attention  has  turned  to  the  manpower 
function,  and  the  training  function  will  follow.  Examination  and  needs/gap  analysis  of  CATS, 
DTMS,  ATIS,  and  all  of  the  systems  and  interfaces  to  which  those  programs  are  linked  should 
prove  to  be  an  interesting  and  informative  exercise.  At  this  point,  there  is  little  information 
available  about  the  purpose  or  goals  of  the  training  subsystem. 

It  is  apparent  that  training  management  systems  are  on  the  minds  and  drawing  boards  of 
many  Army  and  DoD  decision-makers.  Yet  these  are  not  the  visionary  designs  that  will  push 
technology  development  to  address  future  needs.  Advocates  of  CATS,  DTMS,  and  TDDT  will 
point  out,  accurately,  that  users  can  construct  programs  of  instruction  and  exercises,  using  the 
tools  provided.  This  is  not  the  same  as  obtaining  training  support  on-demand — that  is,  with  a 
minimum  of  training  developer  manipulation  of  database  information.  This  point  will  be 
discussed  more  fully  in  the  next  section.  As  of  today,  ATIS  is  probably  the  prime  candidate  for 
addressing  the  needs  for  training  management.  It  may  someday  be  absorbed  into  DIMHRS,  but 
at, this  point  it  has  at  least  some  functionality,  while  the  training  component  of  DIMHRS  has  not 
entered  the  analysis  phase.  According  to  the  ATIS  proponent,  the  ATSC,  ATIS  will  provide  the 
architecture  to  allow  personnel,  resource,  training  and  doctrine  development,  and  other 
applications  to  be  able  to  cross-reference  and  interact  with  one  another  (TADLP,  2005).  It  is 
intended  to  be  the  overarching  tool  for  integrated  training  management. 
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Computer-Generated  Forces  and  Artificial  Intelligence.  Two  related  aspects  are  involved 
in  considering  CGF  progress:  the  visual  representation  and  the  behavioral  representation.  The 
visual  representation,  as  the  name  suggests,  refers  to  the  apparent  realism  of  objects  in 
simulation,  which  is  conveyed  by  physical  details,  shadows,  and  perspective  that  change  to 
correspond  with  the  point  of  view  of  the  person  viewing  the  simulation.  Behavioral 
representation  refers  to  how  objects  move  and  react  to  movements  of  other  objects.  For  humans, 
for  example,  it  includes  walking  and  running,  moving  around  obstacles,  turning  around  to  look  at 
or  listen  to  things,  falling  when  hit  with  a  killing  projectile  (e.g.,  a  bullet).  For  vehicles,  the 
behavioral  representations  include  speed  of  movement  over  various  terrain  types,  blowing  up 
when  hit  by  a  missile,  and  blowing  up  differently  when  an  improvised  explosive  device  (IED) 
goes  off.  Buildings  and  other  terrain  features  don’t  move,  but  they  do  show  different  effects 
when  damaged  in  different  ways.  It  is  in  consideration  of  behavioral  representation  that  AI 
enters  the  discussion,  as  a  way  to  more  accurately  and  quickly  portray  the  behaviors. 

The  areas  of  CGF  and  AI  (and  a  related  area,  human  behavioral  representation)  are  not 
new.  However,  despite  unrelenting  theorizing  and  developments,  they  continue  to  be  important 
topics  for  researchers.  Conference  schedules  for  gamers,  military  system  developers,  and 
medical  training  experts  (among  others)  are  heavy  with  papers  and  presentations  on  faster  and 
more  realistic  techniques,  processes,  and  applications.  Review  of  the  topics  of  recent  CGF- 
related  research  and  presentations,  all  of  which  allude  to  the  use  of  some  form  of  AI, 
demonstrates  the  relevance  of  ongoing  CGF  and  AI  R&D  to  ET  delivery.  A  sampling  of  those 
topics  includes: 

•  Use  of  Performance  Measurement  Objects  (PMO),  which  represent  actors,  behavioral 
data,  and  measurement  methods  and  support  the  real-time  requirements  of  intelligent 
agents,  human  observer/instructors,  and  distributed  performance  assessment  processors 
(Stacy,  Freeman,  Lackey,  &  Merket,  2004). 

•  Standardizing  CGF  behaviors  so  that  composite  behavior  developed  for  one  simulation 
can  be  reused  in  another,  by  having  the  composite  behavior  make  reference  to  primitive 
behaviors  that  are  functionally  equivalent  in  the  two  simulations  (Gerber  &  Lacey, 
2004). 

•  Formalized  behavior  models  for  CGF  entities  that  allow  quick  creation  of  new 
behaviors  and  multiple  variants  and  easy  modification  of  existing  behaviors  (Stottler, 
Lackey,  &  Kirby,  2004). 

•  Integrating  physics-based  damage  effects  in  real-time  urban  simulations  to  represent  the 
visual  aspects  of  damage  and  permit  calculation  of  the  extent  of  damage  and  personnel 
casualties  (Mann,  York,  &  Shankle,  2004), 

•  Use  of  dynamic  procedural  tactics,  wherein  AI  tailors  tactics  to  the  situation  and  terrain 
at  hand  using  on-the-fly  algorithms  and  dynamic  inputs  (Straatman,  van  der  Steeren,  & 
Beij,  2005). 
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•  Methods  for  determining  Iine-of-sight  in  complex  simulated  environments  (University 
of  North  Carolina  at  Chapel  Hill,  2005). 

Visual  representation  is  already  very  good,  especially  for  objects  (as  opposed  to  people), 
and  continues  to  improve.  Behavioral  representation  also  continues  to  improve  with  respect  to 
every  aspect  of  a  virtual  simulation — natural  and  man-made  terrain  features,  vehicles,  humans 
and  animals,  and  munitions.  In  trying  to  extend  virtual  simulations  to  distributed  training,  the 
implementation  of  realistic  behavioral  representations  is  frequently  brought  up  short  by 
considerations  of  bandwidth. 

In  practice,  AI  is  more  distinct  from  CGF  than  CGF  is  from  AI — that  is,  there  tend  to  be 
more  scientific  papers  and  presentations  that  address  AI  apart  from  CGF  than  the  converse.  Still 
there  exists  some  confusion  regarding  the  definition  of  AI.  According  to  the  “Artificial 
Intelligence  Frequently  Asked  Questions  (FAQ)”  website  (Crabbe,  Dubey,  &  Kantrowitz,  2004), 
the  phrase  is  so  broad  that  people  have  found  it  useful  to  divide  AI  into  two  classes:  strong  AI 
and  weak  AI.  Strong  AI  makes  the  bold  claim  that  computers  can  be  made  to  think  on  a  level  (at 
least)  equal  to  humans  and  possibly  even  be  conscious  of  themselves.  Weak  AI  simply  states 
that  some  “thinking-like”  features  can  be  added  to  computers  to  make  them  more  useful  tools 
(e.g.,  expert  systems,  drive-by-wire  cars,  speech  recognition  software)  Subtopics  within  the 
realm  of  AI  include  both  problems  and  solutions: 

•  Automatic  programming — the  task  of  describing  what  a  program  should  do  and  having 
the  AI  system  ‘write’  the  program. 

•  Bayesian  networks — a  technique  of  structuring  and  inferencing  with  probabilistic 
information  (part  of  the  “machine  learning”  problem). 

•  Knowledge  engineering/representation — turning  what  we  know  about  a  particular 
domain  into  a  form  in  which  a  computer  can  understand  it. 

•  Machine  learning — programs  that  learn  from  experience  or  data. 

•  Natural  language  processing  (NLP) — Processing  and  (perhaps)  understanding  human 
(“natural”)  language.  Also  known  as  computational  linguistics. 

•  Neutral  networks  (NN) — The  study  of  programs  that  function  in  a  manner  similar  to 
how  animal  or  human  brains  do. 


•  Planning — given  a  set  of  actions,  a  goal  state,  and  a  present  state,  decide  which  actions 
must  be  taken  so  that  the  present  state  is  turned  into  the  goal  state. 

•  Speech  recognition — Conversion  of  speech  into  text. 

•  Visual  pattern  recognition — The  ability  to  reproduce  the  human  sense  of  sight  on  a 
machine. 
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These  are  the  very  capabilities  and  technologies  that  will  be  needed  to  support  simulation- 
based  training,  as  will  be  shown  later.  The  technologies  are  not  just  theoretical;  they  are  being 
used  broadly  today  for  such  developments  as: 

•  Financial  software,  which  is  used  by  banks  to  scan  credit  card  transactions  for  unusual 
patterns  that  might  signal  fraud. 

•  Applications  of  expert  systems/case-based  reasoning  to  create  a  computerized  leukemia 
diagnosis  system  that  does  a  better  job  checking  for  blood  disorders  than  human 
experts. 

•  Machine  translation  software,  developed  in  the  1 970s,  that  translated  natural  language 
weather  forecasts  between  English  and  French. 

•  Deep  Blue,  the  first  computer  to  beat  the  human  chess  Grandmaster. 

•  Physical  design  analysis  programs,  such  as  for  buildings  and  highways. 

•  Fuzzy  controllers  in  dishwashers,  clothes  dryers,  and  other  common  appliances. 

Even  with  a  very  shallow  understanding  of  CGF  and  AI,  it  is  obvious  that  much  has  been 
accomplished  and  much  remains  to  be  done.  However,  the  possibilities  are  directly  relevant  to 
the  planning  for  adaptive  training  management. 

This  information  on  current  and  near-term-future  database  systems  and  CGF/AI  was  used 
in  formulating  the  use  case  analyses  described  in  the  next  major  section. 

What  Kind  of  Tools  Will  Training  Managers  Accept? 

The  FCS  documentation  and  database  initiatives  described  above  present  a  curious  mix  of 
automated  tools  and  human  intervention.  While  the  FCS  technologies  will  likely  be  able  to  take 
.over  much  of  the  time-consuming  effort  of  planning  training  events  and  preparing  TSPs,  most  of 
the  documentation  still  indicates  that  the  Training  Manager  or  Exercise  Controller  will  prepare 
tactical  materials  for  the  TSP,  make  decisions  about  scenario  events,  determine  initiating 
conditions  for  the  exercise,  control  enemy  and  other  friendly  forces  during  the  exercise,  and 
prepare  and  deliver  the  AAR.  The  capability  for  systems  to  do  the  work  for  individuals  may  not 
mean  that  individuals — especially  commanders — will  be  willing  to  relinquish  control  of  their 
training  events.  This  is  more  than  a  matter  of  job  protection  or  mistrust  of  systems’  abilities  to 
do  as  well  as  humans  (although  there  may  be  some  of  that).  It  is  at  least  partially  the  very  proper 
responsibility  that  the  commanders  feel  for  the  training  of  their  units  and  unit  members,  and  the 
accountability  for  readiness  to  their  higher-ups.  It  may  also  be  a  lingering  reluctance  to  lose 
hands-on  control — and  this  is  the  same  danger  that  commanders  encounter  in  all  of  their 
networked  operations:  they  have  the  capability  to  micromanage,  and  the  appropriate  balance 
between  knowing  and  controlling  continues  to  be  an  issue. 
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In  the  next  major  section,  where  the  use  cases  are  expounded,  we  have  chosen  the  route  on 
which  the  commander  trusts  the  system  completely  to  make  many  of  the  decisions  in  planning, 
preparing,  and  delivering  the  training,  but  also  has  considerable  freedom  to  tweak  the  parameters 
of  a  training  event. 

What  are  the  Near-Term  Solutions? 

This  is  the  crux  of  the  matter.  Given  the  current  status  of  work  on  FCS,  the  timeline  for 
FCS  development  and  production,  the  current  and  emerging  initiatives,  and  the  pace  of 
technology  development,  it  will  be  important  to  forecast  the  likelihood  of  actually  realizing  the 
plans  for  collective  training  using  ET  capabilities.  This  issue  and  some  possible  answers  will  be 
discussed  and  presented  in  a  later  section,  titled  “Issues  and  Recommendations.” 

Non-Issues 

We  also  identified  a  number  of  decision  and  planning  points  that  have  either  already  been 
addressed  or  that  are,  in  the  long  run,  relatively  unimportant  in  determining  the  scope  and 
structure  of  future  training  management.  However,  because  they  contribute  to  our  understanding 
of  the  issues  by  helping  to  restrict  the  scope,  we  describe  them  briefly  here.  They  include: 

•  What  will  the  different  kinds  of  training  be?  All  of  the  FCS  documentation  refers  to 
simulation-based  training,  individual  interactive,  courseware  (ICW)  or  interactive 
multimedia  instruction  (IMI),  and  interactive  electronic  technical  manuals  (IETMs). 

Our  specific  concern  here  is  collective  training — that  is,  simulation-based.  The 
simulations  are  more  specifically  characterized  as  live,  virtual,  or  constructive,  or  some 
combination.  With  embedded  training  capabilities,  distinctions  between  live,  virtual, 
and  constructive  will  blur  even  more  than  they  do  today,  and  all  exercises  will 
necessarily  be  a  combination.  The  more  pertinent  question  concerns  whether  the 
training  be  conducted  on  the  FCS  platforms  completely  in  training  mode  (stationary)  or 
somewhere  else?  The  “somewhere  else,”  which  may  include  the  NRFTT  or  moving 
(live)  FCS  vehicles,  requires  additional  resources  that  the  embedded  training  system 
cannot  itself  supply,  which  requires  some  additional  coordination. 

•  How  will  the  training  products  be  adapted  from  embedded  training  versions  to  run  on 
NRFTT  or  other  means  of  delivery?  They  won’t.  Everything  will  be  constructed  in 
such  a  way  that  the  various  systems  are  entirely  compatible.  The  embedded  training 
system  that  works  for  the  FCS  platform  will  work  in  exactly  the  same  way  for  NRFTT, 
desktops,  personal  digital  assistants  (PDAs),  and  other  devices,  at  least  as  far  as  the 
transmission  of  electrons  is  concerned. 

•  Who  will  be  the  human  training  manager  (HTM)?  As  described  earlier,  the  training 
manager  role  will  be  assumed  by  different  people,  including  unit  commanders  or 
members  of  their  staffs,  for  different  training  events.  While  that  decision  may  be 
reversed  someday,  it  is  a  reasonable  course  of  action,  given  the  fact  that  commanders 
are  in  fact  responsible  for  unit  performance.  The  two  other  roles — exercise  controller 
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and  CGF  operator — should  eventually  be  very  minor  roles  as  the  automated  training 
management  takes  over  those  functions. 

•  How  will  the  HTM  have  time  and  expertise  to  build  the  training  event  and  the  TSP? 
Given  the  projected  sophistication  of  the  FCS  software  services  and  other  performance 
support  systems,  the  HTM  would  need  very  little  in  the  way  of  formal  knowledge  of 
how  to  construct  the  training,  but  would  need  to  understand  the  unit’s  training  needs 
and  have  a  normal  complement  of  tactical  and  operational  expertise.8 

•  How  will  the  HTM  know  what  to  train?  Currently,  task  information  is  found  in  AS  AT 
and  decisions  on  what  to  train  are  based  on  the  unit  METL  and  estimates  of  readiness. 
In  essence,  that  process  will  continue,  although  automated  tools  should  make  the 
information  on  optimal  training  schedules  and  current  unit  proficiency  more  available 
and  more  accurate.  The  task  information  will  have  been  upgraded  and  migrated  to 
ATIS. 

•  How  will  the  HTM  get  the  latest  training  information  and  content  onto  FCS  platforms? 
The  SOSCOE,  with  networked  links  back  to  databases  and  repositories  and  the  Home- 
Station  Operations  Center  (HSOC),  will  access  the  information  when  needed.  Separate 
versions  will  not  be  resident  on  individual  FCS  platforms. 

The  Future  Training  Management  System  (Concept) 

The  vision  for  future  management  of  training  is  for  the  most  part  being  painted  with  a 
fairly  broad  brush.  In  order  to  develop  a  concept  for  future  training  management,  we  brought 
together  the  preliminary  findings  on  FCS  training  designs,  information  and  automation  needs, 
available  tools  and  databases,  and  commander  preferences,  and  used  the  assembled  information 
to  paint  the  more  detailed  picture.  We  focused  on  collective  training,  following  it  through  the 
full  process  of  analysis,  design,  development,  delivery,  and  evaluation,  as  defined  by  the  Army’s 
Systems  Approach  to  Training  in  TRADOC  Regulation  350-70  (DA,  1995). 

Our  process  is  described  below,  followed  by  a  description  of  the  interim  and  final 
conclusions. 

Method 

We  began  with  a  use  case  approach  to  identifying  training  management  issues  and 
describing  the  training  management  system  of  the  future.  Our  assumptions  concerning  the 
available  technologies  were  very  optimistic  (and  were  stated  earlier):  massive  database  systems, 
bi-directional  reach,  sophisticated  self-learning  search  engines,  performance  support  systems,  . 
CGF-simulation  of  conditions  and  participants  powered  by  AI,  and  super-broad  bandwidth.  Not 
all  of  these  are  likely  to  be  ready  for  use  by  the  time  the  FCS  is  fielded  (around  2016-2020). 
Nonetheless,  we  posited  these  capabilities. 


8  W  e  would  say  “a  full  complement  of  tactical  and  operational  expertise”  except  that  that  would  obviate  some  of  the 
need  for  training. 
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Using  the  information  gathered  and  reviewed,  we  prepared  informal  use  cases  for  two  of 
the  major  aspects  of  training  management  described  above:  (1)  planning  and  scheduling  of 
collective  training  events,  and  (2)  conduct  of  collective  training  (including  data  archiving). 

These  two  use  cases  included  the  activities  described  for  the  three  FCS  training  roles  (training 
manager,  exercise  controller,  and  CGF  operator)  although  the  correspondence  was  not 
specifically  delineated.  In  all  cases,  the  principal  figure  (the  actor)  was  the  human,  and  the 
supporting  actor  was  the  training  management  system  and  interface.  By  focusing  first  on  the 
human  user,  we  explored  capabilities  and  features  in  a  user-centric,  rather  than  system-centric, 
mode. 

A  note  on  use  cases:  We  followed  the  guidance  from  Larman  (2002)  in  developing  these 
use  cases.  He  describes  what  he  refers  to  as  casual-style  “black  box”  use  cases;  they  do  not 
describe  the  inner  workings  of  the  system,  but  rather  define  system  responsibilities  in  relation  to 
user  needs.  He  also  suggests  a  presentation  comprising  the  primary  path,  with  extensions  to 
describe  branching  or  alternate  activities.  In  our  use  cases,  the  extensions  are  shown  in  brief 
style,  which  includes  even  less  detail  than  casual  style. 

We  then  analyzed  those  use  cases  to  prepare  secondary  use  cases,  where  the  principal  actor 
was  the  training  management  system  and  interface.  This  had  the  effect  of  focusing  attention  on 
what  actions  the  training  management  system  should  be  able  to  perform  and  how  it  will  be  able 
to  perform  those  actions,  in  support  ofthe  user.  These  elaborated  use  cases  are  closer  to  the 
“fully  dressed”  format  (Larman,  2002). 

From  secondary  use  cases,  we  extracted  training  management  system  actions,  and 
organized  them  according  to  type  of  action  (e.g.,  database  look-up,  report  preparation).  The 
product  of  this  activity  was  a  definition  of  training  management  system  requirements  in  terms  of 
types  of  capabilities  and  features,  as  well  as  specific  capabilities  and  features.  We  then  worked 
backwards  to  identify  critical  “what-if  ’  situations,  possible  workarounds,  priorities  for 
development  that  consider  both  criticality  and  realistic  development  pace,  and  recommendations. 

To  make  the  discussion  easier  to  follow,  we  will  henceforth  refer  to  the  future  training 
management  system  as  the  TMS(C),  which  stands  for  training  management  system  (concept).9 
The  principal  user  of  the  TMS(C)  is  the  training  manager  (the  unit  commander  or  his  designated 
representative)  during  planning  and  development  of  the  training  event,  and  the  unit  itself  during 
conduct  of  the  exercise.  We  will  use  the  pronoun  “he”  when  referring  to  the  user,  with  full 
understanding  that  current  and  future  users  may  be  either  male  or  female. 

All  of  the  interactions  between  the  user  and  the  TMS(C)  will  be  mediated  through  the 
Warrior  Machine  Interface  (WMI),  which  the  user  employs  habitually  to  send  and  receive 
information.  The  WMI  is  the  portal  for  links  to  a  vast  array  of  databases  via  the  SOSCOE.  The 
TMS(C)  will  have  numerous  integrated  routines  to  allow  it  to  access,  analyze,  compile,  report, 
and  archive  data,  and  all  of  this  will  be  completely  transparent  to  the  user.  The  TMS(C)  will 
rarely  print  anything,  although  individuals  can.  Instead,  most  presentation  of  information  will 
occur  via  the  user’s  WMI. 


9  We  are  reluctant  to  propose  a  catchy  name  and  acronym,  for  fear  it  will  stick  and  the  conceptual  description  will  be 
thought  of  as  an  actual  system  and  begin  to  take  on  a  life  of  its  own. 
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Findings — Primary  Use  Cases 

The  first  use  case,  covering  activities  in  preparing  for  a  collective  exercise  (including 
analysis  of  training  needs,  design  of  the  training  event,  and  development  of  the  TSP)  is 
diagrammed  in  Figure  1.  The  actual  conduct  of  the  training  event  (including  both 
implementation  and  evaluation)  is  captured  in  the  second  use  case,  depicted  in  Figure  2. 

Constructing  the  two  use  cases  enabled  us  to  identify  a  number  of  facts  and  assumptions  • 
about  the  user  and  the  TMS(C).  Those  concerning  the  TMS(C)  required  further  analysis  by 
means  of  the  secondary  use  cases  mentioned  earlier.  Those  concerning  the  user— commander, 
training  manager,  or  unit  members — were  primarily  concerned  with  the  decisions  that  he  must 
make  or  would  want  to  make,  and  were  entirely  derived  from  Use  Case  1  (preparation).  These 
included: 

•  Type  of  training — collective  exercise  (unit  or  small  group)  or  individual  training. 

(Note:  For  the  remaining  considerations  concerning  the  user  of  the  TMS(C),  we  will 
follow  the  thread  of  collective  exercises,  not  individual  training.) 

•  Training  venue — on  stationary  FCS  platforms,  in  NRFTT,  on  moving  FCS  systems 
using  augmented  reality,  or  using  other  common  devices  (desktops,  Notebooks,  PDAs, 
etc.) 

•  Level  of  participation — full  or  with  specified  participants  absent. 

•  Preparation  activities — conducting  prerequisite  individual  or  collective  training. 

•  Thumbprint — multiple  opportunities  to  provide  commander’s  input  to  tailor  the  training 
conditions  and  AAR,  and  to  annotate  the  archived  data,  concerning  any  aspect  of  the 
tactical  situation,  exercise  intensity,  scenario  events  and  timeline,  discussion  points  and 
priorities,  analysis  of  performance  data,  readiness  assessment,  etc. 

•  Level  of  assistance  desired  during  the  exercise — multiple  selections  including 
remediate  poorly  performing  Soldiers  one-on-one,  provide  unobtrusive  in-stream 
coaching,  perform  pause-and-coach,  and  make  in-stream  adjustment  to  exercise 
conditions  to  reflect  unit  proficiency  (as  opposed  to  a  straight  run-through  of  the 
exercise  with  no  assistance  other  than  what  the  FCS  BCSS  would  provide  during  actual 
operations). 

•  Other  human  support — whether  or  not  to  have  a  live  Observer/Controller  (O/C)  for 
coaching  and  feedback. 
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Figure  1.  Use  Case  1,  showing  activities  of  the  commander  or  training  manager  in  preparing  for 
a  collective  training  exercise. 
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Figure  2.  Use  Case  2,  showing  activities  of  the  commander  and  other  unit  members  during 
conduct  of  a  collective  training  exercise. 


For  each  of  these  decision  points,  further  analysis  was  needed  to  determine  how  the  user 
would  make  those  decisions — what  information  would  be  available,  what  options  would  be 
offered,  and  which  decisions  could  have  meaningful  defaults.  Additionally,  the  use  case  glosses 
over  such  necessary  activities  as  scheduling,  obtaining  resources,  notifying  and  assisting 
participants,  and  constructing  the  TSP.  The  secondary  use  case  was  intended  to  explicate  those 
activities  in  terms  of  the  performer — the  TMS(C)  or  a  human  exercise  controller. 

Interestingly,  what  Use  Case  2  showed  us  was  that  the  unit  members’  actions  during  the 
exercise  were  completely  focused  on  reacting  to  scenario  conditions  and  events  and  performing 
their  tasks.  The  description  of  their  activities  reads  very  like  a  description  of  actual  combat 
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operations.  Having  all  of  the  scenario  conditions  and  enemy  and  other  friendly  unit  actions 
provided  from  outside  the  unit  is  the  norm  in  large-scale  exercises.  In  today’s  collective 
exercises,  the  commander  might  be  consulted  on  whether  to  adjust  the  exercise  in  mid-stream  in 
response  to  the  unit’s  ability  to  benefit  from  the  experience,  but  this  is  not  usually  the  case.  For 
Use  Case  2,  further  analysis  was  needed  to  determine  whether  the  control  exerted  from  outside 
the  unit  would,  or  should,  come  from  a  human  exercise  controller,  CGF  operator,  or  O/C,  or 
whether,  alternatively,  it  would  come  from  the  TMS(C). 

Findings — Secondary  Use  Cases 

Extending  the  process  used  to  explicate  the  primary  use  cases,  we  prepared  secondary  use 
cases  that  focused  on  the  person(s)  or  system(s)  that  support  the  commander,  training  manager, 
or  unit.  To  the  extent  that  the  support  comes  from  humans,  there  will  be  a  need  for  tertiary  use 
cases  that  expand  on  what  those  humans  need  from  the  TMS(C).  As  will  be  shown  below,  there 
was  rarely  a  need  for  human  participation,  given  the  mature  technologies  described  earlier.  The 
only  real  exceptions  occurred  if,  for  whatever  reason,  the  commander  were  to  elect  to  have  a  live 
O/C,  and  in  the  case  of  live  FCS  exercises,  where  an  exercise  controller  would  direct  the 
activities  of  live  roleplayers. 

Figure  3  shows  the  secondary  analysis  for  Use  Case  1,  development  of  and  preparation  for 
the  training  event.  In  the  diagrams,  the  strand  on  the  right  represents  actions  of  the  user,  which  is 
essentially  the  same  as  what  was  presented  in  Figure  1 .  The  left  strand  shows  what  the  TMS(C) 
provides  to  cue  the  user  or  to  accept  the  user’s  response. 

In  Use  Case  1,  much  of  the  support  for  the  user  is  in  the  form  of  data  that  have  been 
analyzed  and  formatted  to  satisfy  the  user’s  need  for  information  to  support  decision-making.  In 
describing  where  those  data  come  from,  we  make  reference  to  information  available  from  the 
database.  In  fact,  the  database  will  be  a  number  of  databases,  such  as  those  described  earlier, 
that  are  linked — that  is,  able  to  share  information  using  integrated  routines.  It  will  comprise 
multiple  data  tables  or  datasets,  elegantly  structured  so  as  to  minimize  redundancy  and  optimize 
processing  speed.  To  the  user,  however,  it  will  truly  appear  to  be  one  massive  set  of  data.  We 
made  the  assumption  that,  because  the  WMI,  the  TMS(C),  and  a  host  of  other  interfaces  and 
databases  will  be  completely  networked,  each  of  these  will  be  able  to  export  and  import  data 
from  the  others,  seamlessly,  using  integrated  routines  that  provide  usable,  readable  reports  or 
data  tables.  The  interfaces,  wizards,  and  help  functions  in  those  systems  will  be  sufficiently 
well-developed  that  specialized  technicians  will  not  be  required  to  manipulate  bits  and  bytes  to 
enable  viewing  of  usable  information. 
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TMS(C)  provides... 


The  User... 


Figure  3.  Secondary  Use  Case  1,  showing  information  flow  between  the  user  and  Training 
Management  System  (Concept)  during  development  of  an  exercise. 
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The  specific  data  needs  derived  from  Use  Case  1  are  shown  in  Table  1 ,  along  with  a 
generic  indication  of  the  specific  type  of  database  (or  segment  of  a  larger  database)  where  the 
data  would  be  found.  In  Table  1,  the  information  needs  are  listed  in  order  by  source,  so  that  the 
type  of  data  from  each  source  is  obvious.  All  of  the  information  needs  and  types  of  databases 
already  exist  (e.g.,  CATS,  ATIS)  except  for  the  scenario  repository.  In  the  envisioned 
repository,  the  various  components  of  TSPs  will  be  stored  as  objects  that  can  be  searched, 
acquired,  modified,  and  assembled  into  a  logical  and  coherent  TSP  with  no  inconsistencies  or 
loose  ends.  The  TSP  components  will  include  those  listed  in  TRADOC  Regulation  350-70  (DA, 
1995)  for  collective  TSPs,  and  the  specific  objects  stored  in  each  component  table  will  be 
derived  primarily  from  user-produced  TSPs.  Each  object  will  have  metatags  or  hooks  that  define 
the  ways  in  which  objects  can  be  combined.  For  example,  it  would  not  be  logical  to  have  a 
platoon  exercise  in  which  the  platoon  is  expected  to  engage  the  entire  army  of  the  enemy 
country,  nor  to  have  a  brigade-size  element  sent  out  to  take  down  a  single  sniper. 


Table  1 

Use  Case  1  Information  Needs  and  Sources 

Information  Needed  Source 

•  Individual  training  plan,  assignments  and  training  history,  and  current  readiness  status 

for  commander,  staff,  subordinate  unit  commanders . . .  Personnel  database 

•  Individual  and  staff  readiness  (task  proficiency)  for  tasks  in  exercise . . .  Personnel  database 

•  Unit-specific  Combined  Arms  Training  Strategy  (CATS),  Mission  Essential  Task  List 
(METL),  point  in  life  cycle,  unit  proficiency  from  previous  exercises,  unit’s  scheduled 

deployments,  unit’s  personnel  turbulence  histoiy .  Unit  database 

•  Scheduled  training  from  unit  training  calendar .  Unit  database 

•  Available  window(s)  in  training  calendar  with  sufficient  time  for  preparation . ; .  Unit  database 

•  Geographic  location  of  next  likely  deployment .  Unit  database 

•  Intensity  level  appropriate  to  current  proficiency .  Unit  database 

•  Unit  naming  conventions  and  call  signs .  Unit  database 

•  Recommended  training  frequency  for  each  unit  METL  task .  Task  database 

•  Prerequisite  individual  and  collective  tasks  for  each  task  in  exercise .  Task  database 

•  Recommended  venue(s)  for  tasks  in  exercise . . .  Task  database 

•  Time  required  to  train  to  proficiency  from  current  level  .  Task  database 

•  Exercise  specifications  for  initialization . . . .  Task  database 

•  Task  performance  measures,  standards,  and  steps  for  after  action  review  (AAR)  template ....  Task  database 

•  Scenario  events  that  will  cue  task  performance  or  allow  for  task  observation;  include  in 

AAR  template . . . . .  Task  database 

•  Training  resources  by  venue . . . .'. . . . .  Venue  database 

•  Options  for  environmental  conditions  for  venue .  Venue  database 

•  Mission  appropriate  to  unit  type  and  selected  tasks .  Scenario  repository 

•  Exercise  components  that  match  exercise  specifications .  Scenario  repository 

•  Segment  of  selected  terrain  appropriate  for  mission .  Scenario  repository 
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In  every  case,  the  accessed  information  would  be  packaged  so  that  it  is  presented  to  the 
user  in  a  form  that  he  can  use.  In  some  cases,  that  packaging  will  use  pre-formatted  report  or 
table  templates,  supported  by  analytic  routines  that  compare  or  combine  different  bits  of . 
information.  For  example,  in  determining  the  unit’s  readiness  for  an  exercise,  the  information  on 
individual  proficiency  would  be  estimated  (calculated  using  a  developed  algorithm)  from  records 
of  previous  training  and  recent  assignments;  the  results  would  be  used  to  look  up  appropriate 
training  opportunities  to  satisfy  the  need;  the  information  on  all  key  staff  and  subordinate  unit 
commanders  would  be  packaged  using  a  table  template;  and  the  table  would  be  presented  to  the 
user  to  show  critical  training  prerequisites  by  individual. 

In  other  cases,  the  presentation  will  be  in  the  form  of  pick-lists,  which  will  show  options 
for  the  commander  to  select.  For  example,  the  commander  will  be  asked  to  decide  on  the  terrain 
for  the  exercise,  and  will  have  the  option  of  selecting  the  one  most  appropriate  to  his  upcoming 
deployment,  or  one  that  allows  him  to  have  the  unit  practice  those  skills  that  he  deems  critical. 

The  template  and  option  pick  list  needs  identified  by  means  of  the  secondary  analysis  of 
Use  Case  1  are  shown  in  Table  2.  Review  of  the  items  in  the  list  makes  it  fairly  obvious  that 
presenting  the  information  will  not  be  especially  difficult — even  a  COTS  product  like  MS® 
Access®  has  tools  for  reporting  database  information.  Rather,  creating  the  algorithms  and 
analytic  routines  to  transform  the  raw  data  items  shown  in  Table  1  and  the  selected  options  in 


Table  2  into  information  for  the  reports  will  be  the  challenge. 

Table  2 

Use  Case  1  Information  Provided  to  User 

Information  to  be  Provided  .  Form 

•  Recommended  options  for  unit  training,  in  terms  of  mission,  tasks,  terrain,  intensity .  Option  list 

•  Recommended  scheduling  and  venue(s)  options,  with  description  of  preparation  strategy  and 

resource  requirements  for  venue(s) .  Option  list 

•  Options  for  environmental  conditions  for  venue  .  Option  list 

•  Options  for  participation  (subordinate  units,  commanders,  and  staff);  level  of  coaching  (unobtrusive, 
one-on-one,  pause  and  coach);  live  Observer/Controller  (O/C)  or  automated  observation,  feedback, 

and  after  action  review  (AAR);  and  adjustment  of  exercise  intensity  based  on  unit  performance . .  Option  list 

•  Report  on  individual  and  unit  training  status,  readiness  to  participate  in  exercise,  prerequisite 

training  needs,  criticality  of  each  prerequisite,  and  recommended  training  strategy .  Template 

•  AAR  plan  showing  training  objectives,  standards,  and  general  discussion  points . . .  Template 

•  Exercise  overview  comprising  situation  summary,  training  objectives  and  standards,  overview  of 

exercise  events,  terrain  sketch,  and  control  measures . : .  Template 

•  Observation  and  AAR  guidance  for  live  O/C  (as  needed) . ! . . . .  Template 

•  Exercise  specifications  for  networked  reconfigurable  full  task  trainers  (NRFTT)  facility  manager 

(as  needed) .  Template 


Finally,  for  the  commander’s  review  of  the  constructed  exercise,  the  information  will  be 
packaged  and  shown  in  the  form  of  a  4-dimensional  representation  (space  plus  time)  that  will  be 
labeled  with  reference  to  the  tasks  that  are  targeted  in  the  exercise.  This  presentation  will  have 
options  for  the  commander  to  freeze  the  action,  point  to  particular  features,  and  request  changes. 
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For  example,  in  a  platoon  exercise,  the  tools  that  construct  the  TSP  may  have  placed  a  concertina 
obstacle  on  a  road,  and  the  commander  would  rather  the  platoon  encounter  a  suspected  IED. 

In  addition  to  the  needs  to  find  data  and  present  information,  there  will  also  be  a  need  to 
send  information  directly  to  other  users  or  systems:  exercise  dates  to  the  unit  training  calendar, 
resource  requests  to  appropriate  suppliers,  and  facility  reservations  (e.g.,  NRFTT)  to  the  facility 
calendar  or  manager.  These  are  functions  that  are  already  available  in  existing  training 
management  systems,  such  as  DTMS.  It  should  be  noted  that  there  is  no  need  to  send 
initialization  data  for  the  exercise  to  another  system,  as  the  development  of  those  data  and  the 
use  of  the  data  are  both  functions  of  the  TMS(C). 

The  nature  of  the  interaction  between  the  TMS(C)  and  the  unit  members  during  conduct  of 
the  exercise,  as  shown  in  Figure  4,  is  quite  different  from  what  occurs  during  development 
(Figure  3).  The  TMS(C)  will  present  almost  nothing  in  the  form  of  reports  or  option  lists. 

During  the  exercise,  much  of  the  information  will  be  in  the  form  of  simulated  activity  to 
represent  the  behaviors  of  enemy  and  other  friendly  units,  physical  effects  on  battlefield  objects, 
environmental  conditions,  and  the  like  (shown  as  Activities  N-Q  in  Figure  4).  This  will  be  the 
case  whether  the  exercise  unfolds  in  accordance  with  the  developed  TSP,  or  whether  the  TMS(C) 
adjusts  it  based  on  the  unit’s  demonstrated  proficiency  and  need  for  more  (or  less)  challenging 
conditions  (Activity  T).  It  will  also  be  the  case  when  the  TMS(C)  needs  to  simulate  the  activity 
of  any  missing  participants,  whether  that  need  was  identified  during  development  (Figure  3, 
Activity  G)  or  occurs  because  an  individual  is  pulled  off-line  for  remediation  (Activity  S). 

The  simulated  activity  will  be  presented  by  means  of  dynamic,  physics-based  modeling  of 
the  entities  in  the  simulated  environment.  Physics-based  modeling  allows  developers  to  define 
the  structure  and  behavioral  characteristics  of  entities  (e.g.,  vehicles,  units,  physical  objects, 
nonparticipating  unit  members),  in  terms  of  how  they  move  or  act  and  how  they  react.  In  the 
case  of  physical  entities,  other  modeling  will  include  how  they  blow  apart  or  collapse  when 
destroyed,  how  vulnerable  they  are  to  different  hits  (which  are  also  modeled  with 
characteristics),  and  so  on.  For  the  characteristics  of  human  simulations,  the  modeling  will  be 
focused  on  how  they  perform  their  tasks  in  reaction  to  a  variety  of  stimuli  that,  together,  appear 
to  define  unpredictable  situations.  These  behavioral  rule  sets  will  also  have  defined  levels  of 
stochastic  reactions  to  allow  for  the  imperfections  in  modeling.  This  will  permit  the  TMS(C)  to 
control  the  scenario  events  at  a  fairly  high  level,  by  releasing  general  guidance  concerning  events 
and  timing  and  allowing  the  entities  to  operate  according  to  their  rule  sets  within  that  guidance. 

Adjusting  the  difficulty  level  of  the  exercise  will  be  done  in  one  of  two  ways.  As  the 
TMS(C)  compares  unit  performance  to  standards  and  determines  that  the  unit  needs  more  (or 
less)  of  a  challenge,  it  will  search  the  scenario  repository  for  appropriate  TSP  .components  to 
present  the  appropriate  change.  If  the  TMS(C)  locates  likely  TSP  components,  it  will  test  them 
for  realism  and  consistency  with  the  portions  of  the  exercise  already  completed,  modify  as 
needed  to  match  the  difficulty  level,  conditions,  and  objectives  for  the  exercise,  and  swap  them 
into  its  operating  plan  to  replace  the  existing  components.  If  appropriate  TSP  components  do  not 
exist  in  the  scenario  repository  from  previous  training  events  (see  the  final  TMS(C)  activity  in 
Figure  4),  the  TMS(C)  will  construct  those  components  from  an  underlying  physics-based  model 
of  TSP  component  elements. 
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Figure  4.  Secondary  Use  Case  2,  showing  Training  Management  System  (Concept)  activity 
during  conduct  of  an  exercise. 


When  there  is  a  need  for  unobtrusive  coaching,  the  nature  of  the  interaction  will  shift 
slightly  as  the  TMS(C)  presents  leading  questions  or  probes  that  cue  the  individual  unit  member 
to  consider  particular  information  or  perform  particular  actions  (Activity  R).  Providing  more 
direct  remediation  to  individuals  (Activity  S)  or  activating  a  pause  with  directive  instruction 
(Activity  U)  will  put  the  TMS(C)  in  the  anthropomorphic  role  of  a  trainer,  giving  information 
and  asking  questions  rather  than  presenting  cues.  The  AAR  will  also  be  conducted  by  the 
TMS(C),  which  will  play  selected  segments  of  the  recorded  exercise  in  4-dimensional  format  (3- 
dimensional  space  plus  time),  present  discussion  points,  probe  for  additional  analysis,  and 
capture  information  on  identified  strengths  and  weaknesses. 

As  with  development  and  preparation  for  the  exercise  (Use  Case  1),  there  will  be  relatively 
little  need  for  live  trainers  or  controllers.  If  there  is  to  be  a  live  O/C  (selected  by  the  user  during 
development  in  Activity  G),  the  TMS(C)  will  provide  preparation  guidance  and  in-process 
guidance  for  coaching  and  feedback,  and  will  support  the  O/C’s  situational  awareness  by 
'  allowing  him  to  View  the  exercise  from  any  vantage  point  and  to  access  collected  data  about  the 
unit’s  performance.  It  will  also  assist  the  O/C  in  preparing  the  AAR,  conducting  the  AAR 
discussion,  capturing  the  outcomes,  and  preparing  the  report.  Discussions  of  O/C  location,  either 
with  the  unit  or  remote,  will  be  moot:  the  capability  for  distributed  training  will  apply  not  only 
to  the  unit  members  but  also  to  any  observers. 

Similarly,  even  in  the  case  of  “live”  FCS-based  training,  where  the  users  are  moving  their 
vehicles  across  real  terrain  and  viewing  a  combination  of  real  objects  (terrain  features  and  each 
other)  and  virtual  objects  (enemy  and  other  friendly  vehicles,  weapons  effects)  by  means  of 
augmented  reality,  there  will  be  only  a  minimal  need  for  a  human  exercise  controller.  The 
TMS(C)  will  be  able  to  track  activities  of  the  live  FCS  vehicles,  and  control  the  reactions  and 
appearance  of  simulated  objects.  Whether  or  not  we  will  entrust  safety  considerations  and 
control  to  the  TMS(C),  or  require  the  vigilance  of  a  live  exercise  controller,  remains  to  be  seen. 

If  there  is  a  human  controller,  which  there  would  be  if  live  roleplayers  were  used  (for  civilians  or 
enemy  troops,  for  example),  the  TMS(C)  will  provide  streaming  guidance  to  the  human 
controller  on  directing  their  activities.  This  could  even  be  done  when  the  TMS(C)  adjusts  the 
exercise  intensity. 

There  are  two  archiving  activities  shown  in  Figure  4,  both  of  which  will  occur  at  the 
conclusion  of  the  exercise.  The  first  concerns  recording  the  exercise  outcomes.  The  TMS(C) 
will  communicate  directly  with  the  unit  database  to  record  information  on  unit  task  proficiency, 
identified  strengths  and  weaknesses,  and  recommended  next  training.  Information  on  individual 
task  proficiency  will  be  derived  from  the  exercise  records  by  use  of  algorithmic  routines,  and 
recorded  in  the  personnel  database.  These  results  will  then  be  available  to  the  user  when  he  next 
plans  a  training  event.  Note  that  no  roll-up  reports  that  use  the.  separate  data  points  will  need  to 
be  stored,  as  integrated  routines  can  compile  the  reports  as  needed.  (This  relates  to  the  issue  of 
database  normalcy.) 

The  other  type  of  archiving  concerns  preservation  of  the  TSP  for  future  use.  After  an 
exercise  is  completed,  the  TMS(C)  will  make  an  assessment  of  the  utility  of  the  training  event, 
based  on  unit  performance  improvement,  robustness  of  AAR  discussions,  and  general  coherence 
of  the  TSP  components.  The  commander  or  training  manager  will  also  be  asked  if  the  training 
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event  was  useful  for  the  unit.  For  training  that  is  judged  as  effective  and  efficient,  the  TMS(C) 
will  parse  the  TSP  back  into  its  component  pieces,  update  the  metadata  for  pieces  that  were 
modified,  and  archive  the  new,  revised,  and  unrevised  components  to  the  scenario  repository. 

The  Issues  and  the  TMS(C) 

The  expanded  analysis  of  the  two  use  cases,  together  with  examination  of  the  work  already 
being  done  on  training  management  for  current  and  Future  Forces,  allowed  us  to  identify  and 
isolate  a  number  of  needs  that  are  already  being  addressed,  as  well  as  some  that  are  not.  Recall 
the  five  issues  and  the  main  discussion  points: 

•  What  will  future  training  development  and  delivery  be  like?  Discussion  of  FCS 
planning  for  software  services  and  training  roles  was  presented. 

•  What  kind  of  information  and  tools  will  the  user  need?  Discussion  focused  on  two 
situations — unit  leaders  planning  collective  training  and  the  units  participating  in 
adaptable  collective  training. 

•  How  will  the  information  and  tools  be  provided  (or  obtained,  or  produced)?  Four 
current  and  emerging  Army  database  initiatives  were  discussed,  as  well  as  a  brief 
review  of  CGF  and  AI  technologies. 

•  What  kind  of  tools  (i.e.,  how  much  automation)  will  training  managers  accept?  The 
need  for  commanders  to  place  a  personal  imprint  on  exercises  rather  than  allow  a 
TMS(C)  to  make  decisions  and  act  as  the  expert  was  discussed. 

•  What  are  the  near-term  solutions?  Discussion  pertaining  to  this  issue  was  deferred  to 
this  section. 

The  picture  of  future  training  development  and  delivery  in  the  use  cases  is,  we  think, 
comprehensible  and  consistent.  However,  that  picture  and  the  TMS(C)  it  describes  rely  heavily 
on  future  technology  capabilities  for  the  information  and  tools  that  the  user  will  need:  a  complex 
database  system,  bi-directional  reach,  sophisticated  self-learning  search  engines,  performance 
support  systems,  CGF-simulation  of  conditions  and  participants  powered  by  AI,  and  an 
upgraded  bandwidth. 

The  future  in  which  that  picture  can  be  a  reality  is  a  long  way  off,  probably  beyond  the 
2016-2020  timeframe  when  the  first  units  will  be  fully  equipped  with  FCS.  Fortunately,  while 
the  capabilities  are  critical  for  the  use  cases’  picture,  they  are  not  the  sine  qua  non  for  good 
training  to  be  available  to  Future  Forces  by  2016. 

This  brings  us  squarely  to  the  third  issue:  How  will  the  information  and  tools  be  provided? 
If  the  TMS(C)  depends  on  technologies  that  will  not  be  available,  then  the  picture  of  future 
training  changes.  Using  the  use  case  explications  and  our  best  estimate  of  the  maturity  of  those 
capabilities,  we  formulated  interim  solutions,  as  follows  (and  as  summarized  in  Table  3). 


Table  3 

Summary  of  Capability  Needs  and  Research  and  Development  Needs 

Capability  Need  Reality 


Research  and 
Development  Needs 


Databases  -  Easily  accessible,  with  standards  and 
personnel,  specifications  for  interfacing  with  each 
unit,  task,  other;  integrated  reports  and  other  tools 
venue  that  will  make  them  easy  to  use. 


Scenario  Tools  for  developing  and  archiving 
repository  multiple  versions  of  each  training  support 
and  registry  package  (TSP)  component,  finding 

versions  of  the  components  with  specific 
characteristics,  and  combining  selected 
versions  of  the  components  to  build  a 
TSP;  capability  to  modify  components, 
have  modifications  cascade  through  the 
assembled  TSP  and  effect  related 
modifications,  and  check  the  finished  TSP 
product  for  internal  consistency. 

Bi-directional  Overarching  network  that  will  connect  all 
reach  FCS  to  each  other  and  to  their  home- 

station  operations  center  (HSOC),  to 
support  direct  point-to-point  contact; 
provide  access  to  databases  and 
repositories,  remote  observer/controllers 
(O/Cs),  additional  information  about 
tactical  conditions,  and  additional  TSPs. 

Search  Capability  that  indexes  available  content 

engines  and  performs  intelligent  searches;  able  to 
“leam”  and  replicate  quickest  paths  and 
most  usable  content. 

Performance  Multiple  tools  (e.g.,  automated  cognitive 
support  decision  and  planning  aids, 

systems,  communication  and  service  support  aids, 

future  collaborative  problem  solving  aids,  and 

computer-  tools  for  terrain  and  automated  pattern 

generated  analysis), 

forces  (CGF) 
and  AI 

Bandwidth  Increased  bandwidth  for  real-time 

presentation  of  synchronous  simulations 
to  multiple  distributed  participants,  with 
ongoing  data  collection  and  performance 
evaluation,  options  for  observation,  and 
dynamic  automated  adjustments;  reliable 
security  measures  and  multiple 
redundancies. 


Already  underway  (Army  Research  on  data  needs, 
Training  Information  report  needs,  ways  of 

System  [ATIS],  Defense  compiling  and  analyzing 

Integrated  Military  Human  data  to  produce  usable 
Resources  System  results. 

[DIMHRS]). 

Possibility  that  TSP  Repositories  and 

modification  tools  can  be  registration  of  whole  TSPs 
developed.  Unlikely  that  or  large-granularity  TSP 

automated  TSP  components  that  can  be 

construction  tools  will  be  modified  as  needed,  based 
developed.  on  the  six  Future  Combat 

Systems  (FCS)  scenarios. 

Identification  of  TSP 
components  and  possible 
combinatory  rules. 

Highly  likely;  network  is  at  Delineation  of  specific  . 
the  heart  of  FCS.  information  requirements. 


Likely;  still  evolving  with  Investigation  of  most  useful 
no  end  in  sight.  search  engine  capabilities 

and  display  modes. 

Unlikely;  processes  will  Automated  network- 

resemble  the  current  enabled  tools  to  support 

processes,  with  human  training  manager,  exercise 

training  managers,  exercise  controller,  and  CGF 
controllers,  and  CGF  operator, 

operators;  performance 
support  systems  without 
CGF  and  AI  are  likely. 

Highly  likely;  network  is  Research  compression 
essential  for  FCS,  making  techniques  and  effect  on 
bandwidth  solutions  a  data  transmitted;  develop 

central  requirement.  techniques  and  best 

practices  for  workarounds. 
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Database  Systems 

Given  the  progress  that  has  already  been  made  with  CATS  and  with  early  versions  of 
DTMS  and  ATIS,  it  is  likely  that  another  10  years  will  be  sufficient  to  mature  the  TDDT  and 
DIMHRS.  Our  guess  is  that  the  databases  listed  in  Table  1  for  personnel,  unit,  task,  and  venue 
information  will  be  accessible  and  will  have  standards  and  specifications  for  interfacing  with 
each  other.  Furthermore,  they  will  have  integrated  reports  and  other  tools  that  will  make  them 
easy  to  use  for  normal  people  (e.g.,  commanders,  training  managers).  From  a  technology  and 
human  effort  point  of  view,  there  is  no  reason  that  the  databases  should  not  be  operational. 
Considerations  of  data  security  are  integral  to  personnel  database  development  and  use,  and  are 
expected  to  continue  to  be  addressed.  At  the  same  time,  it  will  be  important  to  provide  similar 
safeguards  on  any  systems  that  use  those  databases,  such  as  a  future  training  management 
system. 

The  scenario  repository  referred  to  in  Table  1  and  Use  Case  1  is  another  matter,  somewhat 
further  from  maturity.  It  is,  in  fact,  more  than  a  repository.  The  need  is  for  a  way  to  develop  and 
archive  multiple  versions  of  each  TSP  component,  find  versions  of  the  components  with  specific 
characteristics,  and  combine  selected  versions  of  the  components  to  build  a  TSP.  Furthermore,  it 
must  be  possible  for  an  intelligent  system  such  as  the  TMS(C)  to  modify  components,  to  have 
those  modifications  cascade  through  the  assembled  TSP  and  effect  related  modifications,  and  to 
check  the  finished  TSP  product  for  internal  consistency  (more  on  the  required  intelligence 
below). 

If  anyone  has  identified  ways  to  define  the  specifications  for  TSP  component  objects, 
constructed  the  objects,  or  built  a  repository  and  registry  for  those  objects,  they  are  being  fairly 
secretive  about  it.  Repositories  and  registration  of  TSP  component  objects  may  be  the  bridge  too 
far  for  2016.  If  we  can’t  have  the  capabilities  for  TSP  component  objects,  then  the  next  best 
thing  would  be  repositories  and  registration  of  whole  TSPs  that  can  be  modified  as  needed.  (The 
modification  capability,  related  to  the  AI  requirement,  is  described  below.)  The  scenarios  and 
tactical  situations  around  which  the  first  base  set  of  TSPs  should  be  constructed  can  be  derived 
from  the  six  scenarios  that  are  widely  used  in  the  current  FCS  analytic  work  (Unit  of  Action 
Maneuver  Battle  Laboratory  [UAMBL],  2004). 

This  may  be  a  realistic  goal  for  2016.  Work  being  done  on  the  Content  Object  Repository 
Data  Registration  Architecture  (CORDRA)  is  exploring  ways  to  register  learning  content 
developed  according  to  Shareable  Content  Object  Reference  Model  (SCORM)  specifications, 
and  to  parse  larger  sets  of  content  into  separate  objects  by  means  of  the  object  metadata  (Dodds, 
2004).  Additionally,  the  Institute  of  Electrical  &  Electronics  Engineers  (IEEE)  Learning 
Technology  Standards  Committee  has  formed  a  standards  study  group  to  examine  the 
possibilities  for  interfacing  instructional  systems  and  simulation  systems  (G.  Franks,  personal 
communication).  These  two  initiatives  may  form  the  foundation  for  work  on  constructing  a 
collective  exercise  version  of  the  SCORM  work.  Given  current  and  recent  efforts,  we  would 
anticipate  that  some  versions  of  such  a  system  of  repository  and  registry,  the  specifications  and 
standards,  and  the  TSP  content  to  populate  the  system  may  be  operational  by  2016.  In  fact,  once 
the  repository  and  registry  are  created,  the  content  may  be  registered  by  parsing  constructed 
TSPs  into  component  objects  at  a  fairly  high  level  of  granularity,  as  is  done  with  SCORM- 
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conformant  content  under  the  CORDRA  specifications.  It  seems  likely  that  the  technology 
would  allow  a  working  system,  if  individuals  and  agencies  are  inclined  to  work  on  it. 

Bi-Directional  Reach 

This  is  such  an  integral  requirement  for  the  FCS  that  we  have  every  confidence  (tempered 
by  pessimism  bom  of  experience  with  technology  initiatives)  that  the  necessary  capabilities  will 
be  available.  The  overarching  network  that  will  connect  all  FCS  systems,  not  only  to  each  other 
but  also  to  their  HSOC,  will  support  direct  point-to-point  contact,  eliminating  relays  of 
information.  For  training  management  specifically,  commanders  will  have  access  to  the 
databases  and  repositories  described  above,  to  remote  O/Cs,  to  additional  information  about  the 
tactical  conditions  underlying  the  exercise,  and  to  individual  and  small  group  training  that  can  be 
used  in  preparation  for  the  exercise. 

It  seems  unnecessary  to  describe  an  interim  solution  for  2016.  If  the  capability  is  not 
operational,  it  will  likely  be  a  problem  with  interfaces  among  databases  and  repositories, 
adaptable  search  engines,  or  bandwidth  (described  below),  rather  than  any  inherent  difficulty  in 
enabling  communications. 

Search  Engines 

Powerful  search  engines  are  needed  to  support  both  the  reach  capability  and  the  TSP- 
building  process.  The  user  cannot  be  expected  to  sift  through  all  of  the  available  information 
that  contains  his  chosen  keyword.  Additionally,  trying  to  organize  information  so  that  the  user 
can  look  through  all  available  information  will  be  impossible,  given  the  multiple  users  and  their 
multiple  needs.  Rather,  the  need  is  for  a  powerful  Google-like  search  capability  (sort  of  a 
Googleplex)  that  indexes  available  content  and  performs  intelligent  searches.  Each  time  a  search 
is  performed,  the  system  “learns”  the  quickest  path  and  most  usable  content.  Wall,  Elms, 
Biggers,  and  Sticha  (2004)  developed  a  prototype  knowledge  network  that  looked  at  ways  to 
organize  information,  find  the  most  relevant  information  for  a  user’s  request,  authenticate  the 
information,  and  allow  users  to  add  information  to  the  network.  This  type  of  system  will  be 
needed  to  facilitate  the  reach  capability. 

The  Defense  Advanced  Research  Projects  Agency  (DARPA),  which  invented  the  internet, 
is  moving  far  beyond  Google  in  the  development  of  advanced  search  engines.  For  example,  a 
not-so-recent  DARPA-sponsored  project  at  Insightful  Corporation  led  to  the  development  of  a 
product  known  as  InFact,  based  on  linguistic  normalization  and  making  use  of  sophisticated 
technology  for  modeling  the  morphology,  semantics,  and  syntax  of  languages  (DARPA,  2003). 

It  captures  a  larger  amount  of  information  than  other  search  engines  and  can  “read”  documents 
while  retaining  the  information  content  of  every  sentence.. 

Rather  than  retrieving  information  by  keywords,  as  did  early  search  engines,  or  by 
concepts  and  patterns,  as  did  the  next  generation,  the  third  generation  of  search  engines  will 
retrieve  facts.  The  emerging  technologies  use  language  models  that  examine  morphology  for  the 
analysis  of  word  form,  syntax  for  the  analysis  of  keyword  relationships,  and  semantics  for  the 
analysis  of  overall  linguistic  meaning.  Morphological  and  semantic  analyses  are  not  new  to 
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search  and  retrieval,  but  it  is  the  inclusion  of  the  syntactic  model  that  will  allow  search  engines  to 
understand  meanings  and  duplicate  the  process  of  lexical  comprehension  in  humans. 

Furthermore,  many  of  the  next  generation  search  engines  have  unique  ways  of  grouping  and 
displaying  results  (e.g.,  concept  maps,  concept  spaces,  semantic  webs  and  visualization,  and 
semantic  indexing)  that  make  it  easier  to  find  relevant  information.  They  also  have  the  ability  to 
use  contextual  and  positional  operators,  query  by  example,  query  expansion  using  related  words 
and  concepts,  improved  faceting,  and  data  mining  technologies  to  improve  search  and  retrieval 
results  (S.  Shadrick,  personal  communication). 

In  the  very  near-term,  Google  already  exists.  Further  developing  the  process  and  turning 
the  ’bots  loose  on  the  developed  databases  and  repositories  should  not  be  an  obstacle.  If  nothing 
else,  we  will  have  more  primitive  ways  of  searching  and  accessing  information,  which  means 
things  will  take  longer,  users  will  be  discouraged  by  the  laborious  routines  involved  in  finding 
what  they  need,  and  they  will  stop  searching.  This  capability  has  both  a  high  likelihood  of 
success  and  a  dearth  of  interim  solutions. 

Performance  Support  Systems,  Computer-Generated  Forces  Simulation,  and  Artificial 
Intelligence 

This  discussion  combines  the  topics  of  performance  support  systems  with  considerations  of 
future  CGF  and  AI  because  of  the  nature  of  those  future  performance  systems,  as  described  in- 
FCS  documents.  Many  of  the  most  useful  of  the  planned  systems  for  FCS  will  be  enabled  by 
powerful  CGF  and  AI,  so  that  the  technologies  and  products  are  inextricably  linked. 

The  FCS  program  developers  have  a  strong  commitment  to  performance  support 
systems — that  is,  ways  of  presenting  the  appropriate  information,  at  the  appropriate  time  and 
level  of  specificity,  using  techniques  appropriate  to  the  user’s  ability  and  needs.  Plans  for  FCS 
capabilities  are  rife  with  references  to  various  software  services.  The  need  for  leaders  and  their 
staffs,  as  well  as  system  operators,  to  use  the  same  tools  during  training  that  they  use  in 
operations  is  indisputable.  These  same  tools,  however,  are  also  needed  for  the  TMS(C) 
features.10 

The  distinction  between  training  support  systems  and  performance  support  systems  is 
moot.  If  the  performance  support  systems  are  available  via  the  SOSCOE  in  the  platforms,  and 
embedded  training  is  available  in  the  platforms  via  the  SOSCOE,  then  there  is  no  reason  that 
they  should  not  take  advantage  of  the  same  technology — it  would  be  foolish  to  do  otherwise. 

The  tools  and  software  services  are  of  limited  utility  without  AI,  and  many  also  require 
CGF.  As  described  earlier,  the  related  fields  of  CGF  simulation  and  AI  have  a  long  way  to  go, 
but  also  have  devoted  researchers.  The  adaptive  training  system  requires  both  CGF  and  AI  for 
complete  development  of  the  performance  support  systems,  in  order  to  dynamically  present 
conditions  reactive  to  unit  actions,  evaluate  unit  member  performance  against  competency 
definitions  and  determine  needs  for  coaching  and  remediation,  present  space  and  time  models  for 


10  Descriptions  of  the  specific  software  services  has  not  been  designated  for  open  distribution.  Interested  readers 
should  contact  the  LSI  for  more  information. 
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scenario  development  and  AARs,  construct  internally  consistent  training  events  and  TSPs,  lead 
AAR  discussions  and  recording  results,  and  so  on. 

Engineers  and  programmers  are  already  at  work  on  those  systems  and  technologies,  but  the 
probability  of  success  by  2016  is  moderate  at  best  (in  our  opinion),  despite  some  very  dedicated 
efforts.  Even  if  the  technologies  are  sufficiently  matured  to  permit  the  tools  to  be  deployed, 
there  is  a  distinct  possibility  that  they  will  not  be  assembled  into  the  training  support  tools 
posited  for  the  TMS(C). 

If  the  various  performance  support  tools  are  not  operational  (with  their  supporting  CGF 
and  AI  capabilities),  then  processes  for  training  development  and  execution  will  resemble  the 
current  processes,  where  individual  training  managers,  exercise  controllers,  and  CGF  operators 
make  decisions  and  carry  them  out  with  live  roleplaying  participants  and  only  the  barest  of 
automated  tools.1 1  All  three  of  the  training  management  roles  will  need  to  be  filled  by  humans, 
rather  than  by  computerized  services.  Roleplayers  and  O/Cs  will  require  training  and  their  own 
performance  support,  just  as  they  do  today.  The  TSPs  may  not  need  to  be  predominantly  paper, 
but  they  will  need  human  translation  to  the  simulator  devices,  while  an  instantiated  TMS(C) 
would  actually  serve  as  the  TSP  for  many  purposes  currently  performed  by  humans  with  paper- 
or  computer-delivered  guidance  (e.g.,  providing  standardized  controlled  conditions,  providing 
support  for  feedback). 

If  the  mechanisms  for  automatic  and  intelligent  construction  of  training  events  and  TSPs 
are  not  developed — then  users  should  at  the  very  least  have  semi-automated  tools  such  as  the 
Commander’s  Integrated  Training  Tool  (CITT),  developed  by  ARI  for  the  Close  Combat 
Tactical  Trainer  (CCTT;  Flynn  et  al.,  2001).  That  tool  set  led  the  user  through  a  process  to 
identify  an  appropriate  training  event  and  download  the  matching  TSP.  The  user  could  then 
modify  the  TSP  to  adjust  starting  positions  and  unit  names  and  call  signs,  and  produce  an 
exercise  initialization  file  for  CCTT,  as  well  as  the  other  paper-based  materials  that  would  be 
used  to  guide  unit  preparation,  O/C  activities,  control  of  CGF  during  the  exercise  (by  humans), 
and  AARs.  If  no  TSP  was  found  that  was  close  to  the  identified  training  need,  then  the  user  was 
instructed  in  how  to  develop  the  exercise  specifications  and  the  TSP. 

More. recent  work  at  ARI  is  examining  rapid  scenario  generation  (A.  Cianciolo,  personal 
communication),  although  the  prototype  tools  are  still  only  semi-automated,  largely  requiring 
human  development.  The  Joint  Advanced  Distributed  Learning  (JADL)  Collaborative 
Laboratory  (CoLab)  is  also  pursuing  the  development  of  tools  to  assist  with  development  of 
training  support  materials  (JADL  CoLab,  2005).  Thus,  there  is  some  small  flurry  of  interest  in 
making  the  tools  available.  With  continued  interest  and  effort  at  the  current  pace,  it  should  be 
possible  to  achieve  the  goal  of  developing  the  scenario  repository  and  the  tools  that  will  support 
at  least  a  CITT-like  capability. 


11  These  “barely  automated”  tools  include,  of  course,  semi-automated  forces,  simulated  plan  view  and  out-the- 
window  displays,  templated  reports  and  support  materials,  exercise  initialization  capabilities,  and  other  technology 
advances  that  were  state-of-the-art  only  10  years  ago. 
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Improved  Bandwidth  Capabilities 

The  real-time  presentation  of  synchronous  simulations  to  multiple  distributed  participants, 
with  ongoing  data  collection  and  performance  evaluation,  options  for  observation,  and  dynamic 
automated  adjustments,  will  put  a  severe  strain  on  a  network  with  conventional  bandwidth.  The 
requirements  are  not  only  for  increased  bandwidth,  but  also  for  reliable  security  measures  and 
multiple  redundancies. 

These  are  not  new  thoughts — FCS  developers  and  other  researchers  in  and  around  DoD  are 
well  aware  that  they  will  need  improvements  just  for  operational  purposes — but  may  increase  the 
scope  of  the  requirement.  A  presentation  at  a  recent  DARPA  Tech  (Saleh,  2005),  described 
some  of  the  ongoing  DARPA  research  and  plans  concerning  bandwidth  issues.  The  DoD  Global 
Information  Grid  (GIG)  operates  on  the  backbone  of  the  Global  DoD  Enterprise  Network, 
consisting  of  satellite-based  networks,  optical  core  and  edge  networks,  and  land-based  fixed 
wireless  networks,  all  with  strong  connectivity  to  tactical  wireless  networks. 

Currently,  the  optical  core  of  the  DoD  Enterprise  Network  is  the  GIG  Bandwidth 
Expansion  (GIG-BE),  now  managed  by  the  Defense  Information  Systems  Agency  (DISA).  It  is 
a  state-of-the-art,  fiber-optic  network  with  the  impressive  projected  aggregate  capacity  of  10 
terabits  per  second.  However,  to  enable  powerful  network  centric  warfare  applications,  DARPA 
projects  that  the  next-generation  optical  core  network  must  have  at  least  10  times  the  capacity  of 
GIG-BE  (or  an  aggregate  capacity  of  at  least  100  terabits  per  second).  According  to  DARPA, 
simply  scaling  up  today’s  technology  to  meet  these  enormously  great  demands  is  not  a  viable  . 
answer.  If  we  actually  try  to  do  this,  the  mostly  switching  and  routing  nodes  will  become  too 
expensive,  too  big,  too  power  hungry,  and  far  too  hot.  The  solutions  being  explored  by  DARPA 
focus  in  part  on  creating  the  technologies  for  all-optical  networking,  dense  wavelength-division 
multiplexing,  and  aggressive  optoelectronic  integration. 

For  network-centric  operations  as  envisioned  in  the  FCS  ORD,  the  next-generation  GIG 
must  be  not  only  fast,  but  incredibly  reliable,  self-healing,  and  secure.  If  those  requirements  and 
the  100  terabits  per  second  are  achieved,  and  if  training  management  features  can  share  some  of 
the  future  GIG  capability,  then  it  is  likely  that  bandwidth  will  no  longer  be  an  issue.  . 

Based  on  description  of  efforts  by  DARPA  (among  others),  we  are  cautiously  optimistic 
that,  in  the  next  10  years,  the  bandwidth  capabilities  will  be  orders  of  magnitude  greater  than 
they  are  today,  at  least  for  operations  if  not  for  training.  The  entire  FCS  concept  is  predicated  on 
the  notion  of  completely  networked  systems.  Without  the  fully  capable  network,  FCS  itself  is  in 
peril,  and  embedded  training  in  FCS  is  moot. 

Summary  and  Recommendations . 

Our  recommendations  are  based  on  a  balance  between  what  is  most  critical  for  future 
adaptive  training,  and  what  is  most  achievable  by  the  2016-2020  timeframe.  They  focus  on  the 
technologies  and  the  ensuing  capabilities  (as  opposed  to  the  surrounding  work  involved  in 
making  them  useful,  described  below),  and  target  the  efforts  required  of  psychologists,  military 
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experts,  and  instructional  designers  working  in  close  collaboration  with  engineers  and 
programmers. 


The  work  on  the  databases  should  include  training  experts  who  will  be  able  to  define  and 
describe  the  variables  of  interest,  and  to  delineate  the  connections  among  those  variables. 
Separate  databases  or  segments  (tables)  within  databases  should  not  contain  redundant 
information  or  information  that  can  be  computed  from  existing  data  (again,  the  consideration  of 
normalcy).  Training  experts  should  be  able  to  generate  the  complete  list  of  personnel,  unit,  task, 
and  venue  characteristics  that  are  needed,  draw  the  linkages  and  relationships,  and  tell  why  they 
are  needed  and  how  they  will  be  used  in  clear  and  concise  sentences.  Then,  working  with 
database  designers  and  engineers,  the  team  will  be  able  to  design  the  structure  of  compatible 
databases  that  will  share  information  with  each  other  and  with  users.  They  will  also  be  able  to 
build  the  tools  that  will  allow  users  to  access  appropriate  reports  and  enable  performance  data 
archiving.  This  should  be  an  effort  accorded  some  high  priority,  primarily  because  the  very 
promising  ATIS  and  DIMHRS  initiatives  are  already  underway  and  should  not  be  ignored. 

Additionally,  work  on  scenario  repositories  and  registries  should  expand  to  include 
definition  of  the  scenario  and  TSP  components,  the  ways  in  which  they  are  related  and  can  be 
defined  as  compatible  or  incompatible,  interfaces  and  decision  points  for  human  input,  and 
methods  for  relegating  the  compatibility  decisions  to  an  intelligent  agent.  Work  should  begin  on 
codifying  the  process  for  translating  the  TSP  components  into  coherent  TSPs  with  information 
for  human  users  and  data  bits  used  by  the  services  of  the  embedded  training  TCCs.  The  scope  of 
work  on  the  scenario  repository  is  very  broad,  and  needs  to  be  coordinated  with  work  on  the 
TCCs  and  BCSSs.  We  would  also  consider  this  to  be  a  fairly  high  priority,  not  so  much  because 
of  any  urgency  for  quick  solutions,  but  simply  because  it’s  going  to  take  some  time. 

The  bi-directional  reach  feature  in  support  of  both  training  and  operations  is  already  on  the 
radar  for  FCS  developers  and  engineers.  The  use  of  search  engines  to  facilitate  construction  of 
training  events,  preparation  for  training,  and  obtaining  information  during  training  (as  during 
operations)  is  going  to  take  some  thought.  There  are  significant  bodies  of  research  literature  on 
knowledge  management,  and  the  corpus  expands  daily.  The  role  for  training  experts  here  is  to 
maintain  a  watching  brief  on  knowledge  management  within  the  military  community  and  to  be 
alert  for  ways  to  exploit  emerging  developments.  With  the  passage  of  time,  as  decisions  are 
made,  training  experts  should  become  even  more  active  in  the  process  to  ensure  that  those 
decisions  are  reflected  in  training  management  system  developments.  The  priority  to  monitor  the 
process  is  high,  but  the  effort  is  of  relatively  low  intensity. 

Continuing  development  of  the  FCS  performance  support  systems,  on  the  other  hand,  is 
going  to  be  a  fascinating  area  for  research.  It  is  still  relatively  embryonic,  as  a  vast  array  of 
capabilities  in  CGF  and  AI  are  folded  into  the  mix.  The  use  of  performance  support  systems 
should  be  largely  human-centric,  as  opposed  to  technology-centric,  designed  to  support  human 
needs  rather  than  to  deliver  every  possible  service.  The  involvement  of  experts  in  training, 
military  requirements,  human  factors,  and  cognitive  behaviors  is  essential  to  influence  both  the 
type  of  support  provided  and  the  ways  in  which  it  is  provided.  This  area  is  considered  as  a  high 
priority,  both  monitoring  developments  and  participation  in  design  and  decision-making. 
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The  likelihood  for  success  by  2016  is  not  assured.  It  would  be  wise  for  training  experts  to 
continue  to  work  on  the  interim  solutions:  less  intelligent  performance  support  systems  for 
human  training  managers,  exercise  controllers,  O/Cs,  and  CGF  operators;  CITT-like  tools  to 
facilitate  construction  of  training  events  and  TSPs  from  a  core  set  based  on  the  six  scenarios 
(UAMBL,  2004);  and  templates  that  can  be  used  with  minimal  human  input  supplementing 
database  input  to  provide  reports  on  training  needs  and  accomplishment.  The  development  of 
tools  to  permit  rapid  building  of  training  events  and  TSPs  is  already  being  studied  (ARI,  2005). 
The  performance  support  systems  for  human  training  roles  are  of  particular  interest,  and  should 
be  a  fruitful  area  for  research  to  determine  the  specific  needs  for  each  role,  the  ways  of  delivering 
the  support,  and  the  appropriate  levels  of  automation. 

The  work  on  bandwidth  issues,  including  security  and  redundancy,  is  in  the  hands  of 
engineers.  Our  only  participation  in  these  developments  is  to  stay  informed  on  the  capabilities  so 
that  the  proposed  solutions  do  not  render  the  training  management  system  inoperable.  For 
example,  network  security  measures  that  prevented  exchange  of  information  between  platforms 
during  training  would  be  counterproductive.  Bandwidth  allocation  that  did  not  permit  distributed 
data  collection,  analysis,  and  AARs  would  seriously  impede  conduct  of  distributed  exercises. 

There  are  other  requirements  for  making  the  technologies  and  capabilities  useful,  such  as 
populating  the  databases  with  personnel  and  unit  training  and  experience  information, 
documenting  collective  and  leader  task  analyses,  devising  and  recording  the  baseline  CATS, 
creating  the  starter  set  for  the  scenario  repository  and  registry,  analyzing  the  expert,  collective, 
and  structural  behaviors  that  CGF  and  AI  will  portray,  preparing  task  standards  that  are 
measurable  by  intelligent  systems,  creating  the  individual  training  that  can  be  used  for 
remediation,  among  others.  All  of  these  will  need  attention,  and  findings  will  need  to  be 
integrated  to  permit  exploitation. 

One  issue  stated  earlier  has  been  left  hanging:  What  kind  of  tools  (i.e.,  how  much 
automation)  will  people  accept?  This  is  a  field  for  research  all  by  itself,  and  should  probably  get 
underway  before  all  the  tools  are  built.  The  early  days  of  battlefield  digitization  were 
characterized  by  a  tendency  among  leaders  to  revert  to  voice  communications  when  stressed. 

The  CITT,  despite  the  obvious  advantages  it  afforded  in  saving  time  and  ensuring  completeness, 
is  not  widely  used  today.  In  fact,  a  recent  study  of  CCTT  utility  found  that  company 
commanders  and  platoon  leaders  who  use  CCTT  are  generally  unaware  that  TSPs  are  even 
available  (Mastaglio,  Peterson,  &  Williams,  2004).  Research  might  include  reviews  of  the 
literature  on  automation  acceptance,  interviews  among  military  leaders,  and  even  experimental 
investigation  of  how  trust  and  acceptance  are  formed. 

This  set  of  recommendations  will  be  well  served  by  collaborative  teams  of  training 
developers,  psychologists,  and  military  experts,  similar  to  the  groups  that,  comprise  the  Training 
IPT.  Work  on  the  recommended  courses  of  action  will  support  a  future  training  management 
that  does  not  require  all  of  the  promised  technologies  to  be  delivered,  and  simultaneously 
advances  our  current  understanding  of  and  designs  for  future  training  management.  These 
initiatives  will  help  us  to  identify  avenues  of  research  that  are  promising,  as  well  as  those  that 
will  be  pointless  to  explore.  The  interim  solutions  are  not  the  stop-gap  workarounds  that  are 
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independent  of  the  envisioned  goal.  Rather,  they  are  stepping  stones  on  the  path  toward  the 
eventual  high-end  solutions. 
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Appendix  A 

Acronyms  and  Abbreviations 


AAR 

After  Action  Review 

AI 

Artificial  Intelligence 

ALMS 

Army  Learning  Management  System 

ARI 

U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 

ASAT 

Automated  Systems  Approach  to  Training 

ATIA 

Army  Training  Information  Architecture 

ATIS 

Army  Training  Information  System 

ATRRS 

Army  Training  Requirements  and  Resources  System 

ATSC 

Army  Training  Support  Center 

BCSS 

Battle  Command  Software  Services 

CALL 

Center  for  Army  Lessons  Learned 

CATS 

Combined  Arms  Training  Strategy 

CCTT 

Close  Combat  Tactical  Trainer 

CGF 

Computer-Generated  Forces 

CUT 

Commander’s  Integrated  Training  Tool 

CoLab 

Collaborative  Laboratory 

CORDRA 

Content  Object  Repository  Data  Registration  Architecture 

COTS- 

Commercial-Off-the-shelf 

CTIA 

Common  Training  Instrumentation  Architecture 

DA 

Department  of  the  Army 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DIMHRS 

Defense  Integrated  Military  Human  Resources  System 

DISA 

Defense  Information  Systems  Agency 

DoD 

Department  of  Defense 

DTMS 

Digital  Training  Management  System 

EMilpo 

Electronic  Military  Personnel  Office 

ET 

Embedded  Training 

FAQ 

Frequently  Asked  Questions 

FCS 

Future  Combat  Systems 

GIG 

Global  Information  Grid 

GIG-BE 

Global  Information  Grid  Bandwidth  Expansion 

HSOC 

Home-Station  Operations  Center 

HTM 

Human  Training  Manager 

ICW 

Individual  Interactive  Courseware 

IED 

Improvised  Explosive  Device 

A-l 


IEEE 

IETM 

IMI 

IPT 

ITAPdB 

ITRS 

JADL 

KPP 

LSI 

METL 

MS 

MTO&E 

NLP 

NN 

NRFTT 

O/C 

ORD 

PDA 

PEOSTRI 

PMO 

R&D 

RFMSS 

SCORM 

SIDPERS 

SOSCOE 

TACP 

TADLP 

TADSS 

TAMIS-R 

TCC 

TDDT 

TESS 

TMS(C) 

TO&E 

TRADOC 

TSP 


Institute  of  Electrical  &  Electronics  Engineers 
Interactive  Electronic  Technical  Manual 
Interactive  Multimedia  Instruction 
Integrated  Product  Team 
Integrated  Total  Army  Personnel  Database 
Individual  Training  Readiness  System 

Joint  Advanced  Distributed  Learning 

Key  Performance  Parameter 

Lead  Systems  Integrator 

Mission  Essential  Task  List 
Microsoft 

Modified  Tables  of  Organization  and  Equipment 

Natural  Language  Processing 
Neutral  Networks 

Networked  Reconfigurable  Full  Task  Trainers 

Observer/Controller 

Operational  Requirements  Document 

Personal  Digital  Assistant 

Program  Executive  Office  for  Simulation,  Training,  and  Instrumentation 
Performance  Measurement  Objects 

Research  and  Development 

Range  Facility  Management  Support  System 

Shareable  Content  Object  Reference  Model 
Standard  Installation/Division  Personnel  System 
System  of  Systems  Common  Operating  Environment 

Tactical  Command  Post 

Total  Army  Distance  Learning  Program 

Training  Aids,  Devices,  Simulators,  and  Simulations 

Training  Ammunition  Management  Information  System-Redesign 

Training  Common  Components 

Training  and  Doctrine  Development  Tool 

Tactical  Engagement  Simulation  System 

Training  Management  System  (Concept) 

Tables  of  Organization  and  Equipment 
U.S.  Army  Training  and  Doctrine  Command 
Training  Support  Package 
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UAMBL 

UTMC 

WMI 


Unit  of  Action  Maneuver  Battle  Laboratory 

Unit  Training  Management  Component,  also  Unit  Training  Management 
Configuration 

Warrior  Machine  Interface 
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